接口联调时把对方给的 JSON 示例转成 Java 实体类，看着是体力活，真踩起坑来全是细节。下面 5 个坑是实际项目里反复出现的，生成工具（包括我们自己的 JSON 转 Java 工具）也只能解决一部分。

坑 1：日期字符串的类型猜不准

{"createTime": "2026-10-24 18:00:00"}

JSON 里日期就是字符串，生成器只能给你 String。反序列化时如果目标字段想用手动改成 LocalDateTime，直接改类型会报解析异常，必须配套加注解：

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

时区别忘了，差 8 小时的问题排查起来很隐蔽。

坑 2：null 值字段推断不出类型

{"id": 1, "extInfo": null}

示例数据里恰好是 null，生成器只能给 Object。联调时务必找对方要字段说明，null 只是这一次的值，不代表类型。

坑 3：金额用 double 的精度灾难

{"amount": 19.99}

浮点类型生成 Double 看似合理，一旦涉及金额计算就会遇到 0.1 + 0.2 != 0.3 的老问题。金额字段统一改成 BigDecimal，数据库侧对应 DECIMAL。

坑 4：数组元素类型不一致

{"tags": ["hot", 123, true]}

JSON 规范允许混型数组，Java 静态类型不允许。生成器遇到这种数据通常退化成 List<Object>，实际取值时要逐个 instanceof 判断。更推荐的做法是和对方约定统一类型，从源头解决。

坑 5：嵌套泛型与动态 key

{"result": {"2026-10-24": {"pv": 100}, "2026-10-25": {"pv": 120}}}

key 是日期这种动态值时，不该生成实体类，应该用 Map<String, DailyStat>。同理 Map<String, List<X>> 这类结构，生成器展开的嵌套类往往不如手写 Map 声明清晰。

实操建议

生成工具负责的是骨架：字段名、嵌套层级、数组结构一次到位，省去手写 getter/setter。但日期格式、金额精度、动态 key 这三类语义信息 JSON 示例里根本没有，必须人工确认。把生成结果当作草稿而不是终稿，是最高效的姿势。