FastJSON 又炸了，糙猛快是要还的
内容提要
FastJSON 再曝漏洞，作者借此反思“糙猛快”开发文化：让不可信输入决定类加载是行业通病。Jackson、Java、微软均给出退出路线，FastJSON 却长期将 SafeMode 默认关闭。问题不在单个 Bug，而在于收益今天入账、风险以后挂账的机制。AI 会放大这一风险，拆除人类写代码的限速器。
延伸解读
AutoType 的本质：数据平面越界到控制平面
文章指出，AutoType 让输入中的 @type 决定程序加载哪个类，这已不是“数据如何填充对象”，而是“程序创建什么对象”。当输入不可信时，等于让陌生人参与决定加载哪段代码。这一区分是理解 FastJSON 系列漏洞的关键：普通反序列化仍在数据平面，而 AutoType 触碰了控制平面，风险等级完全不同。
行业对比：退出路线比不犯错更重要
文章对比了 Jackson、Java、微软和 FastJSON 的处理方式。Jackson 引入 PolymorphicTypeValidator 并废弃旧入口；Java 通过 JEP 290/415 加过滤器；微软从 .NET 5 到 9 逐步移除 BinaryFormatter。FastJSON 虽有 SafeMode，却长期默认关闭。作者认为，真正分出高下的不是谁没犯错，而是是否为危险能力安排了明确的退出路线。
糙猛快的会计制度：收益今天入账，风险以后挂账
文章将“糙猛快”定义为一种会计制度：功能上线、性能领先、升级不报错都算成绩，而安全债没有发布日期，也不计入考核。这种机制下，兼容性允许债务展期，却不应允许债务取消到期日。作者强调，问题不在单个 Bug，而在于同一套优先级让安全边界长期像补丁层，跨过七年和一次重写仍以相似形状回来。
AI 放大风险：拆掉人类写代码的限速器
文章认为，AI 没有消灭糙猛快的根因，只是给它加了杠杆。过去写数据库、消息队列等系统本身很难，难度是一道天然刹车；现在生成代码成本骤降，不懂原理也能做出看似像样的版本。更麻烦的是，坏习惯会进入训练数据、检索结果和提示词上下文，以同样笃定的语气传播。作者提醒，模型层没有万能 SafeMode，系统层必须有最小权限、沙箱和确定性授权边界。
Q&A
FastJSON 的 AutoType 功能为什么会导致远程代码执行漏洞？
AutoType 允许输入中的 @type 字段决定程序加载哪个类。当输入不可信时，攻击者可以指定恶意类，导致远程代码执行。这相当于让外部数据参与控制平面决策，而不仅仅是数据填充。
FastJSON 和 Jackson 在处理反序列化安全问题上有什么不同？
Jackson 在 2.10 引入 PolymorphicTypeValidator，要求调用者显式提供类型验证规则，将责任重新摆正；而 FastJSON 虽然提供了 SafeMode，但长期默认关闭，AutoType 也默认关闭但未彻底废弃，导致风险持续存在。
什么是“糙猛快”开发文化？它如何导致安全债务？
“糙猛快”指优先追求功能、性能和快速上线，将安全边界和退出方案推迟。它把收益今天入账、风险以后挂账，形成技术债。这种文化下，安全机制常像补丁层，默认不安全，且缺乏长期治理。
FastJSON 的 SafeMode 是什么？为什么它没有默认开启？
SafeMode 是 FastJSON 1.2.68 引入的安全开关，开启后拒绝所有 AutoType。未默认开启是因为会破坏依赖旧行为的应用兼容性，且 FastJSON 作为第三方库无法强制用户迁移。但文章认为这不能成为不设退出路线的借口。
AI 如何放大“糙猛快”带来的安全风险？
AI 降低了代码生成门槛，拆除了人类写代码的限速器，使坏习惯和过时做法能低成本、大规模传播。同时，AI 没有消灭糙猛快的根因，反而让生成代码更便宜，可能被用于快速构建更多系统，而验证和治理投入未必跟上。
文章认为关键依赖（如 FastJSON）应该如何治理？
关键依赖必须有负责人、响应机制和退出路线，包括明确停止维护的含义、通知下游、提供替代方案和维护最后一个安全版本。安全机制必须失效关闭，文档承诺需与真实行为一致，不可信输入不能无约束进入控制平面。
