1. 从Fastjson到Jackson：一次迟到的技术栈迁移

在Java后端开发这个行当里，JSON序列化库的选择，几乎和“中午吃什么”一样，是个永恒的话题。我自己的项目，从五六年前开始，就一直在用Fastjson。那时候，它凭借“快”这个金字招牌，加上阿里巴巴的光环，迅速成为了很多团队的首选。配置简单，API直观，一句JSON.parseObject()就能解决大部分问题，确实让人用着顺手。然而，几年用下来，随着项目复杂度提升、团队人员更迭，以及外部依赖环境的变化，Fastjson带来的“惊喜”开始多于“顺手”。性能波动、偶发的序列化异常、以及时不时需要关注的漏洞公告，都让我开始重新审视这个“老朋友”。最终，在经历了一次由JSON解析引发的线上小事故后，我下定决心，将核心服务的JSON库从Fastjson全面迁移到了Jackson。这个过程，远不止是改个依赖、换几个API调用那么简单，它更像是一次对项目健壮性和工程实践的深度复盘。

2. Fastjson的“七年之痒”：那些年我们踩过的坑

我最初选择Fastjson的理由和大多数人一样： benchmark数据亮眼，中文文档友好，在特定场景下（比如大量Map、String的序列化）速度确实快。但在长期的生产实践中，尤其是在一个中等规模、迭代频繁的微服务系统中，一些问题逐渐浮出水面，从“小麻烦”变成了“大隐患”。

2.1 默认配置的“宽松”与安全隐患

Fastjson最被诟病的一点，是其默认的“AutoType”特性及宽松的解析策略。为了反序列化时能自动识别类型，它允许在JSON字符串中通过@type指定任意类路径。这在带来便利的同时，也打开了安全风险的潘多拉魔盒。虽然后期版本通过SafeMode等方式进行了限制，但默认行为并非最安全的。我们曾经在对接一个外部老旧系统时，因为对方传过来的JSON格式不可控，触发了Fastjson的异常解析，虽然没有造成直接的安全事故，但报警日志里频繁出现的警告信息，足以让人心惊胆战。

注意：Fastjson的历史漏洞大多与AutoType相关。即使你明确知道自己的服务是内部调用，使用默认配置也意味着在依赖链中埋下了一颗不知道何时会引爆的雷。很多团队都是在出了安全事件后，才紧急升级版本并配置ParserConfig.getGlobalInstance().setSafeMode(true)，这是一种被动的、成本很高的防御姿态。

2.2 性能的不稳定与“魔法”般的优化

Fastjson快，但它的快有时像一种“魔法”。它的高性能很大程度上依赖于底层ASM字节码技术动态生成序列化/反序列化类。这套机制在理想情况下效率极高，但也带来了两个问题：一是首次运行时需要生成类，有一定开销；二是在复杂的类继承关系、泛型、或存在循环引用时，其性能可能会急剧下降，甚至不如一些“稳健派”的库。我们有一个核心的订单详情对象，结构复杂，嵌套深。在QPS高峰时，使用Fastjson序列化该对象的CPU消耗会出现周期性尖刺，排查后发现正是动态生成和加载类导致的。这种性能的不确定性，对于需要稳定延迟的服务来说是致命的。

2.3 社区生态与长期维护的隐忧

尽管Fastjson仍在更新，但其社区活跃度、问题响应速度以及与其他主流Java生态的整合度，逐渐与Jackson、Gson拉开了差距。Spring Boot从1.x到2.x，其默认的JSON处理器就是Jackson，这意味着在Spring生态中，Jackson拥有最好的兼容性和最丰富的特性支持（如与Spring MVC的无缝集成、对@JsonView、@JsonProperty等注解的原生支持）。当你使用Fastjson时，常常需要额外编写配置类来替换默认的HttpMessageConverter，这种“对抗”框架默认行为的方式，不仅增加了复杂度，也容易在框架升级时引入兼容性问题。此外，一些常用的监控、链路追踪工具（如SkyWalking、Pinpoint）对Jackson的序列化性能剖析支持得更好，这也让技术栈的统一显得更有价值。

3. Jackson的“入场”：不仅仅是替换，更是体系化建设

决定迁移后，我并没有简单地find and replace所有import com.alibaba.fastjson。而是将这次迁移视为一个重构项目，制定了清晰的步骤和目标：第一，保证功能完全兼容，零业务逻辑改动；第二，性能不能下降，关键接口要有所提升；第三，借助Jackson的能力，建立更规范的序列化规约。

3.1 依赖引入与基础配置

首先，在pom.xml中，我们移除了fastjson依赖，引入了Jackson的核心三件套：

<dependency> <groupId>com.fasterxml.jackson.core</groupId> <artifactId>jackson-databind</artifactId> <version>2.15.2</version> <!-- 建议使用较新稳定版 --> </dependency> <dependency> <groupId>com.fasterxml.jackson.core</groupId> <artifactId>jackson-core</artifactId> <version>2.15.2</version> </dependency> <dependency> <groupId>com.fasterxml.jackson.core</groupId> <artifactId>jackson-annotations</artifactId> <version>2.15.2</version> </dependency>

如果你的项目用了Spring Boot，那么spring-boot-starter-web已经包含了Jackson，版本由Spring Boot管理，通常无需单独声明。

接下来是配置。在Spring Boot中，Jackson的默认配置通常已经足够合理，但我们仍通过application.yml进行了一些针对性调整，以适应从Fastjson迁移过来的习惯，并提升性能：

spring: jackson: # 日期格式全局配置，统一输出为时间戳，避免时区问题 serialization: write-dates-as-timestamps: true # 忽略未知属性（反序列化时），防止外部传多余字段导致解析失败 deserialization: fail-on-unknown-properties: false # 属性命名策略：驼峰转下划线（与Fastjson的默认TO_UNDERSCORE类似，便于对接） property-naming-strategy: SNAKE_CASE # 不序列化null值，减少传输数据量 default-property-inclusion: non_null

这些配置在HttpMessageConverter生效，影响所有通过Spring MVC进出的JSON数据。

3.2 API迁移的“硬骨头”：习惯与思维的转变

API的迁移是工作量最大的部分。Fastjson的API设计非常“中国化”，简单直接。而Jackson的API更“学院派”和“工业化”，功能强大但稍显繁琐。我们需要一个平滑的过渡方案。

1. 简单对象映射：Fastjson:JSON.parseObject(jsonString, User.class);Jackson:objectMapper.readValue(jsonString, User.class);

2. 复杂类型与泛型：这是差异最大的地方。Fastjson通过TypeReference来处理泛型，而Jackson也有类似但更严格的机制。

// Fastjson 方式 List<User> userList = JSON.parseObject(jsonArrayString, new TypeReference<List<User>>() {}); // Jackson 方式 JavaType javaType = objectMapper.getTypeFactory().constructParametricType(List.class, User.class); List<User> userList = objectMapper.readValue(jsonArrayString, javaType); // 或者使用更简洁的TypeReference（与Fastjson同名，但包不同） List<User> userList = objectMapper.readValue(jsonArrayString, new TypeReference<List<User>>() {});

对于复杂的嵌套泛型，Jackson的TypeFactory提供了更强大和精确的控制能力，虽然代码写起来长一点，但能避免很多运行时类型擦除带来的问题。

3. 配置ObjectMapper实例：在非Spring环境或需要特殊配置时，需要创建和配置ObjectMapper实例。这里的一个最佳实践是使用单例，因为ObjectMapper是线程安全的，但配置过程开销较大。

public class JacksonHolder { private static final ObjectMapper MAPPER = new ObjectMapper(); static { // 禁用将日期序列化为时间戳，采用ISO-8601格式 MAPPER.disable(SerializationFeature.WRITE_DATES_AS_TIMESTAMPS); // 禁用未知属性导致反序列化失败 MAPPER.disable(DeserializationFeature.FAIL_ON_UNKNOWN_PROPERTIES); // 启用美化输出（仅限开发环境） // MAPPER.enable(SerializationFeature.INDENT_OUTPUT); // 注册Java 8时间模块 MAPPER.registerModule(new JavaTimeModule()); } public static ObjectMapper getInstance() { return MAPPER; } }

3.3 注解体系的深度应用

Jackson拥有一套极其强大的注解系统，这是Fastjson相对薄弱的一环。迁移过程也是我们规范POJO定义的好机会。

• @JsonProperty: 定义序列化/反序列化时的字段名。比Fastjson的@JSONField功能更一致。

  public class User { @JsonProperty("user_name") // JSON中显示为 user_name private String userName; }

• @JsonInclude: 控制序列化时包含哪些字段。可以放在类上或字段上，非常灵活。

  @JsonInclude(JsonInclude.Include.NON_NULL) // 全局忽略null public class ResponseDTO<T> { private T data; }

• @JsonView: 实现接口级别的字段过滤。这是Jackson的王牌特性之一，可以根据不同的HTTP接口返回不同的字段集合，完美替代那些手写Map来过滤字段的粗糙做法。

  public class Views { public static class Public {} public static class Internal extends Public {} } public class User { @JsonView(Views.Public.class) private String username; @JsonView(Views.Internal.class) private String email; } // 在Controller中 @GetMapping("/public") @JsonView(Views.Public.class) public User getPublicUser() { ... } @GetMapping("/internal") @JsonView(Views.Internal.class) public User getInternalUser() { ... }

• @JsonFormat: 更精细地控制日期、数字的格式。

  @JsonFormat(pattern = "yyyy-MM-dd HH:mm:ss", timezone = "GMT+8") private Date createTime;

迁移初期，我们为所有核心的DTO和VO加上了必要的Jackson注解，这虽然增加了些工作量，但带来的收益是长期的：代码更清晰，接口行为更可控，再也不用为了一个字段要不要返回而争论不休，一个@JsonView注解就优雅地解决了。

4. 迁移实战：平滑过渡与问题排查

直接全局替换风险极高。我们采用了“双轨运行，逐步替换”的策略。

4.1 策略一：接口层与内部逻辑分离

首先，我们确保所有对外（HTTP API、RPC接口）的序列化/反序列化都通过Spring MVC的HttpMessageConverter完成，而这部分由Spring的Jackson自动配置管理。我们只需要保证Controller入参和出参的POJO兼容Jackson注解即可。对于内部逻辑中散落的Fastjson调用（比如缓存Value的序列化、消息队列消息的编解码），我们将其逐一识别并归类。

4.2 策略二：封装适配器与兼容层

对于暂时无法一次性修改的遗留工具类或第三方SDK调用（它们可能要求传入Fastjson的JSONObject），我们编写了一个轻量级的适配器JsonUtils。这个工具类内部同时持有Jackson的ObjectMapper和Fastjson的解析能力（初期），提供统一的方法。

@Component public class JsonUtils { private final ObjectMapper objectMapper; // Jackson // 初期保留，用于兼容老旧调用 // private static final com.alibaba.fastjson.JSON fastjsonDelegate = ...; public String toJson(Object obj) { try { return objectMapper.writeValueAsString(obj); } catch (JsonProcessingException e) { throw new RuntimeException("Jackson序列化失败", e); } } public <T> T fromJson(String json, Class<T> clazz) { try { return objectMapper.readValue(json, clazz); } catch (JsonProcessingException e) { throw new RuntimeException("Jackson反序列化失败", e); } } // 兼容方法：将对象转为Fastjson风格的JSONObject（逐步淘汰） // public JSONObject toFastJsonObject(Object obj) { ... } }

然后，我们全局搜索JSON.toJSONString和JSON.parseObject，将其逐步替换为JsonUtils.toJson和JsonUtils.fromJson。这样，底层实现的切换对业务代码是透明的。

4.3 遇到的典型问题与解决方案

问题1：日期格式不一致。Fastjson默认的日期格式和Jackson不同，导致反序列化时出错。我们统一在Jackson配置中明确了日期格式（如上文配置），并对历史数据中有特殊格式的字段，在实体类字段上使用@JsonFormat进行精确控制。

问题2：Getter/Setter方法命名不规范导致字段丢失。Jackson默认使用Java Bean规范，通过Getter/Setter方法推断属性。而Fastjson更直接，默认通过字段反射。我们有一个类，字段叫isActive，Getter方法是isActive()，Setter是setActive()。Fastjson序列化后字段是isActive。Jackson则因为发现了isActive()这个getter，会认为属性名是active（去掉is前缀），导致序列化出的字段名为active，下游系统解析失败。解决方法是在字段上显式加上@JsonProperty(“isActive”)。

问题3：空集合与空字符串的序列化差异。Fastjson默认会序列化空集合[]和空字符串“”。Jackson在配置Include.NON_EMPTY时则会忽略它们。这可能导致前端收到字段缺失，引发错误。我们根据接口契约，仔细调整了@JsonInclude的级别，或者在DTO中为集合字段初始化空集合（private List items = new ArrayList<>();），确保行为一致。

问题4：循环引用导致的栈溢出。Fastjson默认通过$ref进行循环引用检测和解决。Jackson则需要显式开启SerializationFeature.FAIL_ON_SELF_REFERENCES或使用@JsonIdentityInfo注解。我们检查了领域模型，发现了几处双向关联，通过@JsonIgnore在序列化方向断开了循环，这反而促使我们重新思考了这些模型的合理性，做了领域重构。

整个迁移过程，我们花了大约两周的碎片时间，分模块进行，每个模块迁移完成后都进行完整的接口测试和性能基准测试。过程中没有引发任何线上事故。

5. 迁移后的收益与反思

完成迁移并稳定运行一段时间后，收益是实实在在的。

首先是心智负担的减轻。再也不用时刻关注Fastjson的漏洞公告，也不用在代码里写各种SerializerFeature和ParseFeature来规避奇怪的行为。Jackson的配置虽然繁多，但逻辑清晰，文档详尽，行为可预测。Spring生态的原生支持，让整合变得无比顺畅。

其次是性能的稳定提升。在我们的基准测试中，对于复杂对象的序列化，Jackson的表现更加稳定，没有出现Fastjson那种首次调用或特定结构下的性能毛刺。JVM的内存占用也更为平稳，因为少了那些动态生成的类。虽然在某些极端简单的场景下，峰值性能可能略逊于极致优化的Fastjson，但对于99%的业务场景，Jackson提供的稳定、可预测的性能更为宝贵。

最后是代码质量的提升。通过全面应用Jackson注解，我们的POJO成为了自描述的契约。@JsonView让我们彻底告别了为了不同接口而新建大量几乎重复的DTO类的时代。代码更干净，意图更明确。

这次迁移给我的最大启示是：技术选型不能只看Benchmark跑分。早期的“快”和“方便”，可能会在项目生命周期的中后期，用更高的维护成本、安全风险和不确定性来偿还。Jackson或许在入门时显得更“重”，但其严谨的设计、强大的功能、健康的社区和深厚的生态，为项目的长期稳健运行提供了坚实的基础。对于一个追求长期主义和技术债可控的团队来说，从Fastjson迁移到Jackson，不是一次简单的库替换，而是一次面向工业级标准的技术栈升级。如果你的项目还在使用Fastjson，并且开始感受到类似的“痒处”，那么现在或许是时候开始评估这次迁移了。