做Java开发这些年几乎每个项目都在跟JSON打交道。接口返回值是JSON前端请求体是JSON消息队列里传的还是JSON。很多朋友一开始觉得JSON处理很简单不就是把对象转成字符串、把字符串转回对象嘛可真到了线上实战字段命名不一致、日期格式错乱、泛型信息丢失、嵌套结构解析失败、循环引用直接栈溢出……哪一个都能让你排查半个下午。这篇内容我不讲空理论直接把我这些年处理JSON的实战经验、踩过的坑和解决方案整理出来从库的选型、核心API、高频边界场景到性能优化和常见报错排查一步一步说清楚适合想把JSON这块彻底吃透的Java后端开发者也适合刚入门想少走弯路的同学。1. Java处理JSON的整体思路与工具选型先聊一个很多人都忽略的问题项目里到底该用哪个JSON库以及为什么不能图省事自己拼字符串。1.1 JSON在Java项目里的定位不是“可选项”是基础设施JSON在Java后端里的角色说是基础设施级别都不夸张。REST接口的数据交换靠它内外系统对接靠它配置中心下发的配置内容绝大多数也是JSON格式消息队列里跑的消息体JSON仍然是绝对的主流格式。正因为到处都在用很多项目组反而把JSON处理当成了“随手就能写”的基础能力直到出了问题才发现原来不同库的默认行为差异这么大。比如某个库默认把null字段也序列化输出某个库遇到未知字段直接抛异常另一个库遇到泛型信息可能悄悄给你塞成LinkedHashMap。这些默认行为一旦在线上触发轻则数据对不上重则接口直接5xx。Java自身是没有内置JSON解析库的这一点不像JavaScript那样天生就有JSON.parse和JSON.stringify。所以第三方库的选择和封装就成了项目里一个必须认真对待的基础设施决策。1.2 主流JSON库对比Jackson、Gson、Fastjson怎么选市面上的Java JSON处理库主流就这三家Jackson、Gson、Fastjson。Jackson在Spring Boot项目里是默认集成的你用Spring MVC写接口时RequestBody、ResponseBody背后干活的就是Jackson。它最大的优势是生态成熟、功能全面、性能也不错。注解体系极其丰富比如JsonProperty、JsonIgnore、JsonFormat还有流式API、树模型API几乎覆盖了你能遇到的所有JSON处理场景。Gson是Google出的API简洁程度是三家里最高的。读代码的时候非常舒服两三行就能完成一次序列化/反序列化。不足之处在于某些高级功能没有Jackson丰富自定义序列化器写起来略繁琐性能上在大批量数据的基准测试里通常略逊于Jackson。Fastjson曾经在国内被大量使用主要原因是中文文档全、上手快、性能宣传点多。但历史上有过多次比较严重的安全漏洞某些公司的安全规范里已经明确禁用了。如果团队里有老项目还在用建议至少是压到最新的稳定版本并且规避掉一些反序列化风险点。对比维度JacksonGsonFastjson生态集成度Spring Boot默认集成生态可扩展性极强集成度一般需自己配合集成度一般部分老项目在用API简洁度中等配置项多简洁直观简洁高级功能注解/流式/树模型/自定义序列化器齐全基础场景够用高级功能稍弱功能多但API稳定性与安全性争议较大性能稳定均衡中等偏弱宣传很强但风险评估后应谨慎推荐场景新项目、企业级后端首选轻量工具、小项目、Android老项目维护若非必要不推荐新引入我给大多数团队的建议是新项目直接选Jackson别犹豫。不是因为Gson不好而是Spring Boot已经把Jackson深度集成到接口层了你再引入一套Gson等于整个项目维护两套序列化体系徒增成本和认知负担。轻量项目、非Spring生态、只是想快速解析一段JSON的场景Gson完全够用。1.3 选型不能只看“哪个火”要看长期维护成本选库这件事很多老开发容易跟风也有团队因为某个库在某些基准测试里快了一点点就全组切换。我认识的一位开发者他们组曾经为了Fastjson的性能优势整体切过去结果后来安全公告一个接一个每个版本升级都要评估影响面反而把开发的效率优势全赔回去了。这其中的核心逻辑是JSON库是全局共享的基础设施不是你写一个工具类核心代码影响范围是整个项目的所有接口行为。所以真正该看的是这几个维度维护活跃度。库是否还在持续发版是否有社区响应漏洞报告。框架集成度。和Spring、数据库框架、消息组件之间的兼容性如何。默认行为的可控性。配置项是否足够开放遇到自定义需求时能不能扩展。团队熟悉度。一个大家都会用、文档丰富的库远比一个局部性能更优但没人能维护的库划算。一句话总结我自己的经验先把Jackson用熟再去了解Gson的生态其他的库保持关注就好。手里有十把钥匙不如把每天都用的那一把彻底磨利。2. Jackson核心实操从ObjectMapper到泛型解析Jackson的所有核心能力都集中在ObjectMapper这个类上。这个类理解了Jackson就掌握了八成。2.1 两个必须刻在脑子里的APIwriteValueAsString与readValue序列化就是把Java对象变成JSON字符串反序列化就是把JSON字符串变回Java对象。ObjectMapper的这套API设计非常直白// 基本用法对象转JSON字符串 UserDTO user new UserDTO(张三, 28); ObjectMapper mapper new ObjectMapper(); String json mapper.writeValueAsString(user);上面这段代码得到的结果就是{name:张三,age:28}。如果UserDTO里的字段名和实际想要输出的JSON字段名不一样后面我会讲到JsonProperty怎么处理。反序列化的核心也是这一行UserDTO user mapper.readValue(json, UserDTO.class);值得注意的是readValue有很多重载方法。除了直接传字符串还可以传byte[]、File、InputStream、Reader甚至可以从JsonNode转换。写文件读取配置、接收HTTP响应体字节流时直接传入对应重载方法即可非常方便。2.2 泛型解析的坑为什么List.class转出来全是LinkedHashMap这是很多刚用Jackson的同学踩的第一个大坑。看这段代码ListUserDTO users mapper.readValue(json, List.class);看起来没问题json也确实是一个JSON数组每个元素都是合法的UserDTO结构。但等你遍历users里的元素时会发现每个元素都是一个LinkedHashMap而不是UserDTO。直接强制转型还会抛ClassCastException。原因在于Java的泛型擦除。在运行时List.class并不知道自己里面应该装什么类型你告诉readValue的只是一个裸的List类型它在运行时看到的只是List自然只能把它当成ListLinkedHashMap来处理。类比一下就是你去快递站取箱子只告诉工作人员“给我搬一个箱子来”没告诉他箱子里面是什么拆箱工具工作人员自然只能把原封不动的箱子交给你里面还塞着各种原始填充材料。正确的做法是使用TypeReference把完整的泛型信息交给JacksonListUserDTO users mapper.readValue( json, new TypeReferenceListUserDTO() {} );花括号破坏了一般的泛型推断规则让Jackson能够在运行时拿到ListUserDTO的完整类型信息。同理MapString, UserDTO、ListMapString, Object这类复杂嵌套结构都需要用TypeReference来解析。我在封装工具类的时候会专门提供对应的重载方法内部直接调用TypeReference版本。2.3 字段映射与命名策略对接第三方接口不再手写一堆put实际开发里最让人头疼的不是结构多复杂而是“字段名字对不上”。比如前端传的JSON字段是user_name你的Java实体字段叫userName第三方接口返回的是OrderID你的DTO字段是orderId。粗暴的解决方案是在反序列化后手动set但字段一多代码全是put和set非常难看很容易漏字段。正确解法是用映射注解或者配置全局命名策略。单字段不一致用JsonPropertypublic class UserDTO { JsonProperty(user_name) private String userName; JsonProperty(order_id) private String orderId; }这样无论JSON里给的是user_name还是user_id都能正确对映到Java字段上。序列化时也会把userName输出为user_name。如果整个项目都统一用下划线命名法就不需要一个字段一个字段去写了。全局设置命名策略即可ObjectMapper mapper new ObjectMapper(); mapper.setPropertyNamingStrategy(PropertyNamingStrategies.SNAKE_CASE);设置之后userName字段会自动匹配user_nameorderId会自动匹配order_id非常省心。再说一个配置细节Jackson 2.12之前的旧写法是PropertyNamingStrategy.SNAKE_CASE2.12开始推荐使用PropertyNamingStrategies.