写JSON处理这个题目其实挺感慨的。入行这么多年从最早手写拼接JSON字符串到后来被各种序列化框架宠坏Java世界里JSON处理早就成了日常开发的基础设施。但越基础的东西坑往往越多——字段命名对不上、泛型被擦除、日期格式翻车、循环引用爆栈……这些老问题隔三差五就能遇到一次。这篇内容就把我在实战里攒下来的Java处理JSON的实用技巧系统梳理一遍从选型思路到进阶玩法再到排查实录尽量讲透讲明白。如果你正在写接口、做数据同步、搞配置解析或者想把自己手里那套JSON处理代码打磨得再稳一点这篇应该能帮你省不少时间。1. 选库是个技术活主流的JSON库到底怎么选1.1 三巨头横向对比侧重看什么维度Java生态里JSON处理库的主流选择其实就是三个Jackson、Gson、Fastjson。只要聊到JSON处理基本绕不开它们。我自己的习惯是先把对比维度列清楚再做选择而不是听别人说哪个火就用哪个。核心对比维度无外乎这几个序列化/反序列化性能接口QPS高不高、数据量大不大的时候性能差距会被放大。API设计友好度注解支持、泛型处理、自定义序列化器是否方便。生态集成度和Spring Boot、HTTP框架、数据库框架的契合程度。维护活跃度与稳定性项目有没有持续维护踩坑之后能不能找到解决方案。内存占用处理超大JSON数据时这方面差异会比较明显。如果只推荐一个我会毫不犹豫说Jackson。理由很现实Spring Boot的默认JSON处理库就是Jackson意味着只要你做Java Web开发Jackson就已经在你依赖里了。与其在项目里同时维护两套JSON工具类不如把Jackson用透。Gson的优势是API极其简洁小工具、Android或者写脚本场景下很好用。Fastjson早期以快出名但历史上有过多次安全漏洞通报在严肃的项目里用起来心理负担比较大。1.2 为什么我更推荐Jackson从工程角度看我自己更倾向于Jackson不只是因为Spring生态绑定。它的工程化能力确实更完整注解机制很全JsonProperty重命名、JsonIgnore忽略字段、JsonFormat格式化日期、JsonInclude控制空值策略基本覆盖了所有日常需求。多方式抽象既支持简单的ObjectMapper方式也支持流式JsonParser读取和JsonGenerator生成大数据量场景下不必换库。自定义扩展能力强可以注册自定义的Serializer和Deserializer适配各种奇葩数据格式。兼容Java新特性对Java 8的Optional、LocalDateTime系列支持非常到位配合jsr310模块处理时间类型很省心。这个选择思路其实可以套用到很多技术选型场景不要单纯看性能报告更要看它和你项目里其他依赖的契合程度以及长期维护成本。用Jackson意味着出了问题社区里很容易找到踩过同样坑的人。2. 对象和JSON互转这些基础操作背后有讲究2.1 基础姿势从最简单的互转开始依赖搞定之后第一件事就是理解ObjectMapper这个核心类。它是线程安全的初始化一次全局复用就好不需要每次转换都new一个省得浪费资源。基本使用分两个方向把Java对象变成JSON字符串用writeValueAsString把JSON字符串变成Java对象用readValue。代码示例如下// 全局维护一个避免频繁创建 private static final ObjectMapper MAPPER new ObjectMapper(); public String toJson(Object obj) throws JsonProcessingException { return MAPPER.writeValueAsString(obj); } public T T fromJson(String json, ClassT clazz) throws JsonProcessingException { return MAPPER.readValue(json, clazz); }类型安全方面要特别注意fromJson返回的是泛型T但底层其实是通过传入的Class来实现反序列化的所以传User.class才能得到User。很多人一开始会写出MAPPER.readValue(json, UserDTO.class)但接收方写Map.class结果反序列化逻辑混乱。保持两侧类型一致是基本素养。2.2 字段命名和忽略策略后端字段和前端字段不一致怎么办接口对接时最常遇到的情况就是前端给的字段名是下划线风格而后端Java类是驼峰风格或者前端多传了几个无用字段。两个问题分别对症下药。下划线风格映射可以加注解public class UserVO { JsonProperty(user_name) private String userName; JsonProperty(user_age) private Integer userAge; }加了注解之后user_name就能正确绑定到userName字段上。如果项目里所有字段都是这种风格不需要一个个加注解直接全局配置命名策略更省事ObjectMapper mapper new ObjectMapper(); mapper.setPropertyNamingStrategy(PropertyNamingStrategies.SNAKE_CASE);这样所有驼峰字段转出来的JSON都会自动变成下划线字段。同理KEBAB_CASE会输出短横线风格LOWER_CAMEL_CASE是默认的驼峰风格。前端传来的JSON里偶尔会多出一些后端不需要的字段比如冗余信息、前端兜底数据。默认情况下Jackson遇到未知字段会抛异常直接影响到业务处理。线上环境一般建议关闭这个报错反正多几个字段不影响反序列化主流程mapper.configure(DeserializationFeature.FAIL_ON_UNKNOWN_PROPERTIES, false);2.3 空值处理配好全局策略省心一半Java对象里很多字段可能是null但接口返回给前端的JSON里大量出现field: null其实很不友好既增加传输体积也容易让前端判断逻辑变繁琐。全局配置一下即可mapper.setSerializationInclusion(JsonInclude.Include.NON_NULL);配了之后序列化时所有值为null的字段都会自动省略。如果还想把空字符串、空集合也过滤掉可以用NON_EMPTY。不过要留个心眼如果前端强依赖某些字段必须永远存在就算null也要显示那就不适合全局过滤还是用JsonInclude在具体字段上单独控制更稳。3. 进阶玩法泛型擦除、嵌套结构、自定义序列化器3.1 TypeReference解决泛型擦除这个Java老问题这是Java处理JSON时最经典的坑。readValue传List.class时Jackson确实能拿到List但List里面每个元素是什么类型由于Java泛型擦除运行时ListUser和List没有任何区别而Jackson只能根据你传入的Class来决定目标结构于是它把每个元素都解析成了LinkedHashMap而不是User对象。解决办法是用TypeReference在匿名内部类里通过反射保留泛型信息ListUser userList MAPPER.readValue(json, new TypeReferenceListUser() {});不只是ListMapString, User、ListMapString, Object这类嵌套泛型结构统统推荐用TypeReference。实际项目中我几乎不给readValue传纯Class除非那个类型真的是简单的DTO。注意一点TypeReference是个抽象类要使用匿名内部类才能带出类型信息。直接写new TypeReferenceListUser()这种表达式效果也是一样的因为Java会保留这段泛型签名。3.2 嵌套结构解析Map套Map还是定义DTO面对复杂嵌套JSON常见做法有两种直接解析成Map结构或者定义对应的DTO类。直接解析成Map适合不需要关心所有字段的场景MapString, Object data MAPPER.readValue(json, new TypeReferenceMapString, Object() {}); String name (String) data.get(name); MapString, Object info (MapString, Object) data.get(info);但这种写法的缺点是所有取值都要强转字段一多代码就变得极难维护只要结构一变到处都是ClassCastException。所以能用DTO解决的尽量用DTO。定义一个结构对应的类里面嵌套定义子对象利用Jackson天然支持对象嵌套解析的特性public class ApiResponse { private Integer code; private String message; private Data data; public static class Data { private User user; private ListOrder orders; // getter/setter } }这样反序列化时Jackson会递归地把整个JSON树填进对象里业务代码取数据时类型明确、可读性高。这是长期项目里更推荐的方案Map适合临时调试或者结构极不稳定的场景越正式的接口对接越应该走DTO路线。3.3 自定义序列化器遇见特殊情况别慌有些字段的序列化逻辑非常个性化比如枚举想输出描述文本而不是name或者某个对象只想输出ID和某个拼接好的展示字符串。这类需求不需要大动干戈写一个自定义序列化器注册进去就行。一个典型的枚举序列化例子public class OrderStatusSerializer extends JsonSerializerOrderStatus { Override public void serialize(OrderStatus status, JsonGenerator gen, SerializerProvider serializers) throws IOException { gen.writeString(status.getDescription()); } }使用的时候在字段上标注JsonSerialize(using OrderStatusSerializer.class) private OrderStatus status;反序列化也同理继承JsonDeserializerT重写deserialize方法支持把前端传来的描述文本变回枚举。这类自定义能力其实非常实用——前端要的数据显示格式、内部存储的数据格式、接口传输格式可以通过自定义序列化器在不影响业务代码的情况下解耦。4. 性能与细节这几个配置能让接口更稳更快4.1 日期格式化LocalDateTime的坑一次说完日期时间格式化是JSON处理里翻车概率最高的点。如果直接序列化LocalDateTime默认输出的可能是数组格式年、月、日、时、分、秒的整数列表前端根本没法直接用。推荐做法是字段上直接标注JsonFormatJsonFormat(pattern yyyy-MM-dd HH:mm:ss) private LocalDateTime createTime;如果是全局需求比如所有日期字段都用同一种格式可以注册一个JavaTimeModule并自定义LocalDateTime的Serializer和Deserializer。使用Jackson的jsr310模块时本质上也是注册模块所以自己注册扩展版也很自然。实际开发中还遇到过时区问题服务器系统时区和数据库时区不一致导致时间差8小时。Jackson序列化时间时可以配合TimeZone设置mapper.setTimeZone(TimeZone.getTimeZone(GMT8));这行配置千万别省尤其是在多租户、跨地域部署的项目里时区不一致造成的bug排查起来极其痛苦。4.2 流式解析与生成处理大JSON时的另一个姿势常规的readValue和writeValueAsString会把整个JSON加载进内存。如果JSON特别大——比如配置文件几十MB、数据同步接口一次性返回上万条记录一次性加载就会出现OOM风险。Spark、Flink、大数据计算平台里经常传超大型JSON报文这时候建议用Jackson的流式APIJsonFactory factory new JsonFactory(); JsonParser parser factory.createParser(jsonStr); while (parser.nextToken() ! null) { JsonToken token parser.currentToken(); if (token JsonToken.FIELD_NAME) { String fieldName parser.currentName(); if (name.equals(fieldName)) { parser.nextToken(); String value parser.getValueAsString(); // 处理字段值 } } }这种方式是逐Token推进的不会把所有数据一次性全部加载进对象树或内存列表里适合超大报文场景。生成端也类似用JsonGenerator逐个写入字段避免构造巨大的中间对象集合。不过日常Web接口开发绝大多数场景用不到这么精细的控制知道有流式方案兜底就行。4.3 异常处理与容错怎么让JSON解析失败不影响主流程从外部系统接收的JSON数据格式是不可控的。一个字段类型不匹配、一段嵌套结构缺失都可能导致反序列化异常。业务代码里完全不处理的话一条脏数据就能让整批处理挂掉。常用的异常兜底方式有捕获JsonProcessingException记录日志并跳过。配置FAIL_ON_UNKNOWN_PROPERTIES为false忽略未知字段。针对不确定类型用JsonNode解析后再校验比如MAPPER.readTree(json)拿到树节点再用get(xxx)判断字段是否存在。JsonNode是另一个很实用的类型它把JSON解析成一棵树可以随时查询想要的字段。适合那种响应里只有部分字段感兴趣又不想定义整个DTO的场景。如果字段类型和预期不一致检查isTextual、isNumber后再取值可以避免很多ClassCastException。5. 实战排查实录那些年我修过的JSON问题5.1 循环引用导致StackOverflow两个对象互相引用比如订单包含用户、用户又绑定了最近订单集合序列化时Jackson一路遍历下去直接栈溢出。解决方案一般是加JsonIgnore打破循环或者在双向引用上升级为JsonManagedReference和JsonBackReference。再复杂一点可以用JsonIdentityInfo让它输出引用ID而不是展开整个对象。我个人最常用的是业务层控制返回前手动把不需要的字段置空或使用专门对外的VO类虽然代码多一点但结构最清晰可控。5.2 字段类型变化引发的解析失败有一次排查线上问题发现接口报错是因为某个字段原来是Integer后来上游系统改成了String类型。数值型的123字符串Jackson可以自动转成Integer但如果是空字符串就会直接失败。处理办法是自定义反序列化器兼容空串和缺失值public class FlexibleIntegerDeserializer extends JsonDeserializerInteger { Override public Integer deserialize(JsonParser p, DeserializationContext ctxt) throws IOException { String value p.getValueAsString(); if (value null || value.isEmpty()) { return null; } return Integer.valueOf(value.trim()); } }这种兼容策略在对接第三方系统时非常管用毕竟你没法要求所有上游系统永远遵循同一个类型规范。同理布尔值也可能出现true、1、yes这类自定义格式只要写好对应的Deserializer就能把外部脏数据隔离在系统边界。5.3 默认值丢失问题有时候对象里的字段初始化了默认值比如private String status PENDING;。但反序列化的执行顺序是先创建一个空对象然后根据JSON内容填充字段。如果JSON里根本没有这个字段——比如前端没传——默认值一般是保留的。但如果JSON里显式传了status: null那么空值策略又没有配置字段就真的被覆盖成null。这个行为看似简单实际项目里很容易造成线上问题。建议给这类字段加JsonSetter的null处理或者干脆配置setSerializationInclusion配合反序列化的ACCEPT_EMPTY_STRING_AS_NULL_OBJECT选项把所有边界行为统一起来。最稳妥的做法是在DTO里不写默认值而是用getter返回兜底值public String getStatus() { return status ! null ? status : PENDING; }这样无论JSON怎么变业务代码读到的一定是有意义的对象不会被null贯穿全链路。5.4 大驼峰缩写的字段名问题Java里有些字段用大写缩写比如userID的ID全大写JSON里写成userID没问题但有时候JSON里是user_id或者userId映射关系就会变得混乱。因为Jackson默认严格匹配字段名大小写敏感、下划线敏感。处理这类问题除了前面说的JsonProperty显式指定也可以自定义命名策略或者统一规范整个团队的字段命名约定。开发过程中最省心的方式是定一个接口规范后端一律返回驼峰前端一律使用驼峰如果存在第三方系统差异才在适配层做映射。不要把命名转换逻辑散落在业务代码里后期改起来会非常痛苦。5.5 大对象字段裁剪JsonIgnoreProperties的妙用反序列化时如果不想接收某些字段可以用类级别的JsonIgnoreProperties效果和JsonIgnore一样但更适合批量操作JsonIgnoreProperties(ignoreUnknown true) public class ThirdPartyOrderDTO { private String orderId; // 忽略第三方系统的冗余字段 }这其实也属于容错策略的一部分。比如某第三方回调接口的报文结构经常更新今天多一个字段、明天少一个字段我们只关心其中的核心字段其他字段一律不管。JsonIgnoreProperties(ignoreUnknown true)直接让你不感知这种结构变化稳定性和开发效率都能提升。最后分享一点实战经验以我自己的经验JSON处理这件事跟很多基础组件一样核心不是会调用API而是把配置、容错、命名规范提前想清楚。别等线上跑了一段时间再回头补配置那时候各种历史包袱已经压在代码上了。把ObjectMapper统一封装成一个配置类、全局只初始化一次、把时区和命名策略固定下来、把空值和未知字段行为开好这套配置做完能省后面一大半排查时间。另外一个小技巧开发调试阶段可以临时开启Jackson的pretty print让日志里的JSON可读一些但线上千万别开那会白白增加不少传输体积和IO开销。封装一个工具类时可以同时提供compact和pretty两个方法方便本地调试和线上日志切换。JSON处理说起来简单用起来全是细节。希望这篇沉淀能帮你少踩几个坑。