JSON工具类选型：Fastjson再爆洞后，项目中该用谁

大家好，我是程序员天天困。

2026 年 7 月，Fastjson 1.x 又爆远程代码执行洞，JSON工具类选型这事又被拎到台面上。按阿里官方安全公告致谢，发现并负责任披露的是 FearsOff 研究员 Kirill Firsov——影响面覆盖 1.2.68～1.2.83，连当年被当成“安全终点”的 1.2.83 也没能幸免。更扎心的是：默认解析入口就能走，不依赖第三方 gadget，SafeMode 没开就中招。还只看谁解析更快，真的会踩雷。

洞一公开，国内厂商也很快跟上。奇安信 CERT 在 2026-07-20 发了风险通告：

腾讯云安全通告页落款是 2026-07-23，同样点名 CVE-2026-16723，并强调这是 gadget-free（不靠 classpath 里额外危险类）的反序列化 RCE：

下面我会把这次洞、历史坑，以及 Jackson / Gson / Hutool 怎么选，一次讲清楚。点个收藏，我们开始。

一、这次 Fastjson 漏洞 CVE-2026-16723 到底怎么回事

以 2026 年 7 月底为准，还在用 Fastjson 1.2.68～1.2.83 解析不可信 JSON 的项目，应优先当事故处理，而不是当“听说有个洞”。

时间线按一手源、按日期排一下更清楚：

1）FearsOff / Kirill Firsov 发现并负责任披露（阿里官方公告致谢）
2）奇安信 CERT 风险通告公开时间 2026-07-20
3）阿里 fastjson2 官方安全公告 标注发布日 2026-07-21（后于 07-29 更新）

4）腾讯云安全通告 页落款 2026-07-23

别被二手文章里的“统一 7 月 20 日”带偏——以各家页面自己写的日期为准。

阿里官方公告里写得很直白：

• CVE：CVE-2026-16723
• 影响版本（官方）：fastjson 1.2.68～1.2.83（含 1.x 最后一版 1.2.83）
• 触发条件：默认配置即可（AutoType 关、SafeMode 关），不需要 classpath 上再塞第三方 gadget
• 常见部署前置：目标跑在 Spring Boot 可执行 fat-jar（java -jar xxx.jar）
• 入口：JSON.parse、JSON.parseObject(String)、甚至 JSON.parseObject(String, Class) 都可达——指定 DTO 也不是银弹，Object/Map 字段里照样能嵌 payload

腾讯云通告也把核心特征写死了：无需依赖特定第三方类库即可打到 RCE，未开 SafeMode 的 1.x 实例在其通告范围内。有个细节要注意：腾讯云通告写的影响版本是 1.2.37～1.2.83，比阿里官方 wiki 的 1.2.68～1.2.83 更宽；做版本自查时，我建议以阿里官方安全公告为准，同时把云厂商通告当风险信号，别互相打架。

说人话：以前很多团队以为「AutoType 关掉就安全了」。这次官方确认，默认关掉也能走通危险路径。更扎心的是，1.2.83 曾是 CVE-2022-25845 的修复终点，很多人停在这里就再也没动过。

官方给出的 P0 动作也很清楚（公告更新于 2026-07-29）：

1）升到 fastjson 1.2.84（2026-07-29 安全修复版）
2）或立刻开 SafeMode（-Dfastjson.parser.safeMode=true / ParserConfig.getGlobalInstance().setSafeMode(true)）
3）或迁到 fastjson2（此 CVE 从架构上不受影响）

另外公告末尾提醒：fastjson2 还有独立的 AutoType 加固问题，请升到 2.0.63 及以上。别把「不受这个 CVE 影响」理解成「永远不用升级」。发现与披露致谢见同一份官方 wiki（Kirill Firsov / FearsOff）。

补充一句时效：腾讯云通告发出时还写“官方暂未发 1.x 补丁、建议迁 2.x / 开 SafeMode”；到 2026-07-29，阿里已经放出 1.2.84。读旧通告时记得对一下后续补丁。

二、Fastjson 历史里几次真正伤人的洞

Fastjson 的安全史，本质上是一条 AutoType 攻防拉锯线，不是偶发的“手滑 bug”。

AutoType（自动类型）：反序列化时允许 JSON 里用 @type 指定具体 Java 类，库再去加载并实例化。类比：快递单上你自己填“收件人是谁”，快递员按你写的门牌送——写错还是小事，写成危险地址就麻烦了。

几条经得起一手源核对的节点：

1）CVE-2017-18349：Fastjson 1.2.25 之前，parseObject 可被构造请求打到远程代码执行，NVD 给出 CVSS 3.x 9.8。（NVD：CVE-2017-18349）

2）CVE-2022-25845：Fastjson 1.2.83 之前，默认关闭 AutoType 仍可被绕过，反序列化不可信数据可打远程服务器。（阿里云漏洞库 AVD-2022-25845，披露 2022-06-11）

3）1.2.83 → 1.2.84：2022 年大家把 1.2.83 当终点；2026 年 7 月又证明终点会移动。仓库若早已归档、业务又停在 1.x，风险窗口会特别长。

中间还有一串 AutoType / JNDI 相关的补丁版本（例如社区常提的 1.2.48 附近加固），细节不必背全，记住一句就够：只要你还在解析外部不可信 JSON，Fastjson 1.x 就不该是“装完忘”的依赖。

三、Spring Boot 里常见 JSON 工具怎么分工

在 Spring Boot 项目里，HTTP 出入参的默认选手通常是 Jackson，不是 Fastjson。

Jackson：Java 里最常见的 JSON 序列化/反序列化库，Spring MVC / Spring Boot 默认集成。类比：厨房里自带的那把主厨刀，日常切什么都先找它。

Gson：Google 出品的 JSON 库，API 顺手，注解体系清晰。类比：外出野餐带的折叠刀——好用、好带，但不一定是你后厨主力。

Hutool JSONUtil：Hutool 这个 Java 工具全家桶里的 JSON 快捷方法，偏“写业务辅助代码时顺手转一下”。类比：工具柜里的多功能钳，拧螺丝、剪线都行，但别拿它当手术刀接公网不可信流量。

可能有人会问：我记得还有个跟 Hutool 很像的“啥都能干”的库？常见是 Guava 或 Jodd。Guava 强在集合、缓存、并发工具，本身几乎不当 JSON 引擎，团队里往往和 Gson 搭配；Jodd 也有 JSON 模块，但国内 Spring Boot 项目里出现频率通常低于 Hutool。选型别把“工具全家桶”和“专用 JSON 引擎”混成一件事。

Spring Boot 默认链路大致是：@RequestBody / @ResponseBody → HttpMessageConverter → Jackson 的 ObjectMapper。你在业务里再引一套 Fastjson，等于同一项目两套规则——日期格式、空值、多态、异常行为都可能对不上。

// 示例：业务里自己再套一层时，先想清楚是不是真需要第二套引擎
ObjectMapper mapper = new ObjectMapper();
UserDTO user = mapper.readValue(json, UserDTO.class);
String out = mapper.writeValueAsString(user);

四、Fastjson、Jackson、Gson、Hutool 怎么比

JSON工具类选型时，我优先看“是否解析不可信输入”，其次才看 API 爽不爽、跑分漂不漂亮。

维度	Jackson	Fastjson / Fastjson2	Gson	Hutool JSONUtil
Spring Boot 契合	默认集成，最省心	需额外接入	可接，非默认	非 HTTP 层默认方案
安全口碑（接公网）	相对稳，仍要控多态配置	1.x 历史包袱重；2.x 需跟版本	通常更克制	取决于你怎么用、解析什么
API 手感	注解强、可定制深	静态方法很香	学习曲线平	工具类超顺手
更适合	Web API、复杂对象图	性能敏感且能跟版本治理	简单 DTO、工具脚本	内部工具代码、快速转换

社区里 JMH / 批量对比文章不少，结论经常是：小对象谁都差不多；大对象、批量场景 Fastjson2 / Jackson 常更亮眼，Gson、Hutool 更偏易用。跑分能参考，但不能替代安全与生态判断——尤其你刚看完 CVE-2026-16723。

你可能会想：那 Fastjson 和 Jackson 对比，性能党是不是必须上 Fastjson？我更建议——先确认你有没有可感知的性能瓶颈。很多接口慢在 DB、远程调用、日志，不在 JSON。真要压榨解析，再评估 Fastjson2，并且把版本升级、SafeMode/白名单策略写进规范，别靠口头约定。

五、我认为项目里该怎么选

以 2026 年 8 月为准，我的默认立场：新 Spring Boot 项目 HTTP 层用 Jackson；遗留 Fastjson 1.x 先止血再谈迁移。

落地顺序我会这么排：

1）新项目 / 主链路：跟 Spring Boot，用 Jackson。日期、时区、未知字段、多态用注解和统一 ObjectMapper Bean 管起来。
2）已经在用 Fastjson 1.x：立刻盘点版本。落在 1.2.68～1.2.83 且解析外部 JSON，按官方建议升 1.2.84 或开 SafeMode，中长期迁 fastjson2（≥2.0.63） 或干脆回到 Jackson。
3）Gson：适合 SDK、小工具、对 Google 生态更熟的团队；当第二套引擎可以，别和 Jackson 在同一条 HTTP 链路上打架。
4）Hutool JSONUtil：继续用在内部转换、测试代码、非不可信输入场景没问题；不建议把它当成对外 API 的唯一反序列化方案。
5）Fastjson2：可以选，前提是团队愿意跟版本、愿意做回归；别再把“国内流行”当成安全背书。

举个常见场景：一个老电商订单服务，controller 用 Jackson，消息消费和几个工具类却散落着 Fastjson 1.2.7x。一做依赖扫描就一堆洞，后面统一迁移的成本，往往比一开始定规矩更高。选型省下来的那点“写起来爽”，后面都会连本带利还回去。

---

以 2026 年中的风险面看，Spring Boot 项目把 Jackson 当默认 JSON 引擎，通常比死磕 Fastjson 1.x 更省心。

JSON工具类选型没有永恒正确答案，但有明确错误答案：把停更的 Fastjson 1.x 默认配置，继续裸奔在公网入参上。

我是程序员天天困，持续分享编程干货。觉得有用的话记得点赞收藏和关注~也欢迎在评论区聊聊：你们公司项目里现在用的是 Jackson、Fastjson2、Gson 还是 Hutool，踩过哪些坑？