Java集合转JSON常见问题在于转得不对：数据丢失、类型变更、null处理不一致、时间格式混乱、循环引用报错；根源在序列化器配置和元素可序列化性，需统一null策略、正确处理泛型、配置非标类型序列化器、断开循环引用。
Java集合转JSON时，最常踩的坑不是“转不了”，而是“转得不对”——数据丢了、类型变了、null被忽略、时间格式乱、循环引用直接报错。核心问题往往出在序列化器配置和集合元素本身的可序列化性上。
空值与null处理不一致
默认情况下，不同JSON库对null的处理差异很大：Jackson默认会输出"key": null，而Fastjson 1.x默认跳过null字段（需显式配置SerializerFeature.WriteMapNullValue）；Gson则默认保留null。如果前端依赖字段存在性做逻辑判断，null被静默丢弃就会引发bug。
- 统一配置全局null策略，比如Jackson中用
@JsonInclude(JsonInclude.Include.NON_NULL)或ObjectMapper.setSerializationInclusion(JsonInclude.Include.NON_NULL) - 避免在DTO中混用包装类和基本类型（如
Integervsint），后者无法表示null，序列化时会变成0或false - 若需区分“未设置”和“明确为null”，考虑用Optional或自定义序列化器
泛型擦除导致反序列化失败
Java运行时擦除泛型信息，List序列化成JSON后只是普通数组，反序列化时若只传List.class，Jackson/Gson会还原成List，而不是List。
- 反序列化集合必须提供带泛型的TypeReference：Jackson用
mapper.readValue(json, new TypeReference；Gson用- >() {})
gson.fromJson(json, new TypeToken- >() {}.getType())
- 避免直接用
Class参数解析带泛型的集合，那是“假泛型” - 若集合元素是接口或抽象类，需注册子类型（如Jackson的
@JsonSubTypes）
时间类型、BigDecimal等非标准类型格式混乱
LocalDateTime、BigDecimal、枚举等类型，不配置序列化器时可能输出成时间戳数字、科学计数法字符串，或直接抛异常。
- Jackson：添加
JavaTimeModule支持JSR310类型，配合@JsonFormat(pattern = "yyyy-MM-dd HH:mm:ss")控制格式 - BigDecimal：默认可能转成指数形式（如
1E+2），用DecimalModeAsString或自定义序列化器确保输出为"100.00" - 枚举：默认序列化为name()，如需转义或自定义值，加
@JsonValue方法
循环引用与不可序列化对象
集合中包含Hibernate/JPA实体（含双向关联）、ThreadLocal变量、InputStream等，极易触发NotSerializableException或栈溢出。
- 提前清理集合中的代理对象或懒加载字段（如调用
Hibernate.initialize()后剔除$$_hibernate_*属性） - Jackson开启
SerializationFeature.FAIL_ON_EMPTY_BEANS快速暴露无getter的类 - 用
@JsonIgnore或@JsonBackReference断开循环引用，而非依赖库自动处理 - 禁止将
this、内部类实例、匿名类塞进集合再序列化
基本上就这些。不复杂但容易忽略——关键不在“会不会转”，而在“转得是否可控、可预期”。选好一个主流库（推荐Jackson），统一配置，再把泛型、null、时间、循环这四关守住了，90%的问题就消失了。
