阿里 fastjson：Java 项目里用得最多的 JSON 库

做 Java 开发的人，几乎都绕不开 JSON 处理。接口要传 JSON，配置文件读 JSON，日志里也经常塞 JSON。怎么把 Java 对象和 JSON 字符串互相转，是每个项目都要解决的基础问题。

阿里的 fastjson 就是干这个的。它在 GitHub 上有 2.5 万多个 Star，在国内 Java 生态里属于用得非常广的基础库。

两个方法搞定大部分场景

fastjson 的核心 API 设计得很简单。想把对象转成 JSON 字符串，调 toJSONString()；想把 JSON 字符串解析成对象，调 parseObject()。两个方法，覆盖了日常开发里绝大多数场景。

// 对象转 JSON
String json = JSON.toJSONString(user);

// JSON 转对象
User user = JSON.parseObject(json, User.class);

不只是简单的 POJO，它对泛型、嵌套对象、集合类型都有支持。你有一个 List<Map<String, Object>> 这种复杂的嵌套结构，它也能正确处理。这点在实际项目里很实用，因为真实的数据结构往往没那么规整。

性能是它站住脚的原因

fastjson 当年能火，核心原因就一个：快。在服务端场景下，JSON 序列化和反序列化的性能直接影响接口响应时间。fastjson 在各种 benchmark 里表现都不错，尤其在处理大对象和复杂结构时优势明显。

它内部用了一些优化手段，比如基于 ASM 的字节码生成、缓存序列化元数据等。这些技术细节普通使用者不需要关心，但效果是能感受到的——同样的数据量，fastjson 的处理速度确实比不少同类库要快。

接入方式

Maven 项目加一段依赖就行：

<dependency>
    <groupId>com.alibaba</groupId>
    <artifactId>fastjson</artifactId>
    <version>2.0.31</version>
</dependency>

Gradle 项目同样一行搞定。基本上加完依赖，代码里 import 一下就能用，不需要额外配置。

1.x 和 2.x 的关系

现在 fastjson 有两个大版本在维护。1.x 是老版本，用的人最多，但历史上出过几次安全漏洞。2.x 是重写版本，性能更好，安全性也做了加固。官方建议新项目直接用 2.x，老项目有条件的话也尽量升级。

升级的成本不算高，核心 API 基本兼容，主要是包名和一些高级用法有变化。官方提供了升级指南，照着改就行。

实际使用中要注意的事

第一，fastjson 有一些"方便"的功能，比如自动类型识别。这个功能在 1.x 时代出过安全问题，因为它会根据 JSON 里的 @type 字段自动实例化任意类，如果 JSON 来源不可信，就可能被利用。2.x 版本默认关掉了这个行为，1.x 的话需要注意配置。

第二，错误处理。JSON 格式不对的时候，fastjson 会抛异常。线上环境要做好捕获，别让一个格式错误的请求把整个接口搞挂。

第三，和其他库的兼容。有些项目可能同时依赖了 fastjson 和 Jackson 或者 Gson，偶尔会有注解冲突的情况。如果团队统一用 fastjson，最好在项目里明确规范，避免混用。

什么场景适合用

如果你的项目是 Java 技术栈，特别是后端服务，fastjson 是一个成熟的选择。国内用的人多，遇到问题搜中文资料基本都能找到解决方案。阿里的很多内部项目也在用，维护力度有保障。

如果你对安全性比较敏感，或者项目已经在用 Jackson 且运行稳定，那就没必要换了。工具选型没有绝对的好坏，关键是匹配团队的技术栈和需求。

比较敏感，或者项目已经在用 Jackson 且运行稳定，那就没必要换了。工具选型没有绝对的好坏，关键是匹配团队的技术栈和需求。