首次披露：XML解析成功后，John为何无声消失

当 JSON 中的浮点数会因依赖树里的一个 Cargo feature 被误判为 map，当 XML 解析“成功”后却悄悄丢掉了一个作者名，问题就不只是 API 使用细节，而是序列化架构如何保存格式信息、管理解析状态与约束资源。 本期「Andrej Karpathy的RSS订阅清单」深度解析 Flask 创始人 Armin Ronacher 对 Rust Serde 的反思，以及他为何打造 Deser：一种让数据格式主动向类型推送事件、保留上下文与位置信息的全新序列化方案。欢迎结合原文阅读，了解可靠解析背后的真实取舍。 原文链接： https://lucumr.pocoo.org/2026/9/29/deser/ 原文标题：Deser: Rethinking Rust Serialization 主要内容： • Serde 在 `arbitrary_precision`、内部标签枚举与缓存交织时，可能将 `1.5` 等数字以 map 交给目标类型；而 Cargo feature 的统一机制会让结果受间接依赖影响。 • `flatten`、自定义反序列化适配器等场景会因中间缓存丢失类型和格式信息，带来难定位的错误与难以组合的代码。 • Deser 反转了解析控制流：格式驱动事件、类型提供 sink，并将进度状态置于堆上的 arena，支持暂停、续传、跨线程处理与可预算的嵌套限制。 • 统一状态管理让精确报错、路径追踪、输入限制、校验、键重命名和原生 `flatten` 成为可组合的解析层。 • XML 案例揭示最危险的失败模式：重复的 creator 字段经缓存后被覆盖，程序无报错回退为 map，导致 John 消失、只剩 Jane。 推荐理由： 这不是一篇单纯比较 Rust 序列化库性能的文章，而是一次从真实生产问题出发的架构复盘。它清楚展示了“解析成功”并不等于“数据正确”，并把 API 设计、依赖 feature、错误定位、流式处理、资源安全与生态迁移成本放在同一张图里讨论。无论你使用 Rust、设计数据管道，还是处理不可信输入，都值得深入阅读原文。 --- 「Andrej Karpathy的RSS订阅清单」为您精选全球最前沿的AI技术博客文章，深度剖析技术背后的核心洞察。 由 voieech.com 提供技术支持。