在需求迭代开发过程中，有测试团队的小伙伴反馈在 RN 页面 偶尔会出现 crash，且堆栈只有一行，指向了MMKV，看完之后一头雾水，为什么 RN 页面会出现 MMKV的 crash，而且堆栈为什么只有一行，其实这些都和 unwind 有直接和间接的关系。就此问题而言，虽然 crash 平台的堆栈只有一行，但是通过抓取到的墓碑文件，可以看到此问题和 __gxx_personality_v0 相关。自 RN 升级到 0.72.5 版本之后，已经是第三次出现和 __gxx_personality_v0 相关的 crash。 为什么 crash 堆栈只有一行？为什么 RN 的 crash 会指向MMKV？让我们带着这些疑问来详细了解一下unwind。
得物DBA自2020年初开始自建TiDB，5年以来随着NewSQL数据库迭代发展、运维体系逐步完善、产品自身能力逐步提升，接入业务涵盖了多个业务线和关键场景。从第一套TIDB v4.0.9 版本开始，到后来v4.0.11、v5.1.1、v5.3.0，在经历了各种 BUG 踩坑、问题调试后，最终稳定在 TIDB 5.3.3 版本。伴随着业务高速增长、数据量逐步增多，对 TiDB 的稳定性及性能也带来更多挑战和新的问题。为了应对这些问题，DBA团队决定对 TiDB 进行一次版本升级，收敛版本到7.5.x。本文基于内部的实践情况，从架构、新特性、升级方案及收益等几个方向讲述 TiDB 的升级之旅。
在电商交易领域，管理类目作为业务责权划分、统筹、管理核心载体，随着业务复杂性的提高，其规则调整频率从最初的 1 次 / 季度到多次 / 季度，三级类目的规则复杂度也呈指数级上升。传统依赖数仓底层更新的方式暴露出三大痛点： 行业无法自主、快速调管理类目；业务管理类目规则调整，不支持校验类目覆盖范围是否有重复/遗漏，延长交付周期；规则变更成功后、下游系统响应滞后，无法及时应用最新类目规则。 本文将从技术视角解析 “管理类目配置线上化” 项目如何通过全链路技术驱动，将规则迭代周期缩短至 1-2 天。
你是否曾在社区搜索时遇到这样的困扰：想找一双“平价学生党球鞋”，结果出现的多是限量联名款？或者输入“初冬轻薄通勤羽绒服”，却看到厚重登山款？这类“搜不准”的情况，正是搜索相关性技术要解决的核心问题——让搜索引擎更准确地理解用户意图，返回真正匹配的结果。今天，我们就来揭秘得物如何用大模型技术让搜索变得更“聪明”。 搜索相关性，即衡量搜索结果与用户查询的匹配程度，通俗来说就是“搜得准不准”。作为搜索体验的基石，良好的相关性能够帮助用户更顺畅地从种草走向决策，同时也对购买转化率和用户留存具有重要影响。
在 RAG 系统中，即便采用性能卓越的 LLM 并反复打磨 Prompt，问答仍可能出现上下文缺失、事实性错误或拼接不连贯等问题。多数团队会频繁更换检索算法与 Embedding模型，但收益常常有限。真正的瓶颈，往往潜伏在数据入库之前的一个细节——文档分块（chunking）。不当的分块会破坏语义边界，拆散关键线索并与噪声纠缠，使被检索的片段呈现“顺序错乱、信息残缺”的面貌。在这样的输入下，再强大的模型也难以基于支离破碎的知识推理出完整、可靠的答案。某种意义上，分块质量几乎决定了RAG的性能上限——它决定知识是以连贯的上下文呈现，还是退化为无法拼合的碎片。 在实际场景中，最常见的错误是按固定长度生硬切割，忽略文档的结构与语义：定义与信息被切开、表头与数据分离、步骤说明被截断、代码与注释脱节，结果就是召回命中却无法支撑结论，甚至诱发幻觉与错误引用。相反，高质量的分块应尽量贴合自然边界（标题、段落、列表、表格、代码块等），以适度重叠保持上下文连续，并保留必要的来源与章节元数据，确保可追溯与重排可用。当分块尊重文档的叙事与结构时，检索的相关性与答案的事实一致性往往显著提升，远胜于一味更换向量
为什么得物需要自建大数据研发与管理平台？ 得物作为一家数据驱动型互联网企业，数据使用的效率、质量、成本，极大影响了公司的商业竞争力。而数据链路上最关键的系统是计算存储引擎和数据研发平台。其中计算存储引擎决定了数据的使用成本，数据研发平台则决定了数据的交付效率、数据质量以及数据架构合理性。
Apex以vscode插件为主要载体，接入SSO认证、打通CursorRules知识库、Webview远程UI、实现无感安装MCP、创建智能体、使用智能体等能力，帮助实现提示词撰写效率的提升，降低了使用过程的费力度。通过知识库、智能体等可实现在保障代码质量同时，进一步提升AI代码生成占比。 除了功能层面的能力，想必大家对Apex内部实现原理应该也很感兴趣，如何打通知识库、智能体使用时，MCP为什么自动安装了，下面将从技术实现角度，剖析Apex 如何将“AI 能力”工程化落地到 Cursor 开发流程中。了解Apex是如何激活装配、打通SSO认证，同步 Cursor Rules 知识库、通过远程dist包实现webview UI渲染，并提供智能体能力，实现无感更新，消息如何编排，如何识别大仓还是独立应用等。
Fastjson 是阿里巴巴开源的高性能 JSON 序列化处理库，其主要以处理小数据时速度最快而著称，功能全面。Fastjson1.X版本目前已停止维护，被Fastjson2.X代替，但1.X版本国内被广泛使用，通过学习其技术架构，剖析架构上优缺点，对技术人员提升软件设计工程实践能力很有价值。 首先我们对“序列化 / 反序列化”概念上建立直观认识，把Java对象转化为JSON格式的字符串的过程叫做序列化操作，反之则叫反序列化。如果把“序列化 / 反序列化”放到整个计算机系统的坐标系里，可以把它看成一次数据的“跨边界搬家”。 对象在“内存世界”里活得很好，但只要一离开进程地址空间（网络、磁盘、数据库、浏览器、异构语言），就必须先打成包裹（序列化），到对岸再拆包裹（反序列化）。
为什么进行源码角度的深度解析？ 大家在项目中到处都在使用线程池做一些性能接口层次的优化，原先串行的多个远程调用，因为rt过高，通过线程池批量异步优化，从而降低rt。还有像RocketMQ中broker启动时，同时通过ScheduledThreadPoolExecutor线程池执行其他组件的定时任务，每隔一段时间处理相关的任务。线程池广泛的应用在外面各种实际开发场景中，我们很多同学可能在项目里只是简单的copy了一些前人的代码参数并不知道其中的含义，从而导致生产级别的bug。所以本篇文章，旨在帮助还不熟悉或者想要熟悉线程池的同学，分享我自己在学习线程池源码上的一些内容来更简单、快速的掌握线程池。
