Fastjson 1.2.68+默认禁用autoType引发拒绝或ClassNotFoundException，需显式白名单开启；Jackson静默失败因字段不可见或无参构造器缺失；日期格式、并发性能差异需统一配置与复用实例。
Fastjson反序列化时出现autoType拒绝或ClassNotFoundException
Fastjson 1.2.68+ 默认关闭了 autoType，老项目升级后常直接抛 com.alibaba.fastjson.JSONException: autoType is not support。这不是配置漏了，是安全策略强制收紧。
- 如果必须用
autoType（比如动态类型字段），得显式开启并白名单控制：ParserConfig.getGlobalInstance().addAccept("com.example.")，别用* - 更推荐改代码：把泛型信息写死，用
JSON.parseObject(json, MyClass.class)替代JSON.parse(json) - 注意
JSON.parseObject(json, Object.class)仍会触发autoType检查——它等价于无类型解析，不是“安全兜底”
Jackson反序列化失败但没报错，字段全为null或默认值
Jackson 默认只识别 public 字段或带 public getter/setter 的字段。如果类用了 Lombok 的 @Data 但没加 @NoArgsConstructor，或字段是 private final 且没构造器参数匹配，就会静默跳过赋值。
- 检查目标类是否有无参构造器（Lombok 记得加
@NoArgsConstructor） - 确认字段命名和 JSON key 完全一致，或已配
@JsonProperty("xxx")；Jackson 不默认处理下划线转驼峰（需配PropertyNamingStrategies.SNAKE_CASE） - 开启日志看实际解析路径：
ObjectMapper.enable(DeserializationFeature.FAIL_ON_UNKNOWN_PROPERTIES)，能快速暴露字段不匹配问题
Fastjson 和 Jackson 在日期格式处理上行为不一致
Fastjson 默认把 java.util.Date 序列化成时间戳（long），Jackson 默认输出 ISO 8601 字符串（如 "2023-05-12T10:30:45.123+0800"）。两边混用时，前端可能收到字符串又收到数字，解析直接崩。
- Fastjson 统一输出字符串：
JSON.toJSONString(obj, SerializerFeature.WriteDateUseDateFormat) - Jackson 统一输出时间戳：
ObjectMapper.registerModule(new JavaTimeModule()).disable(SerializationFeature.WRITE_DATES_AS_TIMESTAMPS) - 更稳妥的是统一用
LocalDateTime+ 显式格式器，避免依赖库默认行为
高并发下 Fastjson 的 JSON.parseObject() 比 Jackson readValue() 慢
不是因为 Fastjson 本身慢，而是它每次调用都隐式新建 DefaultJSONParser，而 Jackson 的 ObjectMapper 是线程安全、可复用的单例。实测在 QPS > 500 场景下，Fastjson 频繁 GC 压力明显更高。
立即学习“Java免费学习笔记（深入）”；
- Jackson 必须复用同一个
ObjectMapper实例，别每次 new - Fastjson 若坚持用，至少缓存
ParserConfig和SerializeConfig，但不如直接切 Jackson 省心 - 注意 Jackson 的
ObjectMapper初始化较重，首次调用会有延迟，建议在应用启动时预热一次readValue("{}", Object.class)
类型推导、字段可见性、序列化策略、线程模型——这些地方一旦没对齐，JSON 转换就变成黑盒调试。尤其当两个库在同一个项目里共存时，连异常堆栈都可能误导人。
