JSON 转 Java:转换差异、边界与常见坑

在线 JSON 转 Java:生成 POJO 并区分基本类型与包装类型,同时标注哪些字段需要 Jackson 或 Gson 注解才能正确映射,减少生成后手工补注解的时间。

生成的是不绑定 JSON 库的纯 POJO,因此 snake_case 键不会自动映射——需要自己加 @JsonProperty 或 @SerializedName。基本类型与包装类型的取舍也有明确规则:允许 null 或允许字段缺失的,一律用包装类型。

两种格式的差异对照

维度JSONJava POJO
命名camelCase / snake_case 混用camelCase 属性,用注解映射线上名
可空性字段可缺失、可为 null基本类型不能为 null,需包装类型
数字类型统一 numberint/long/BigDecimal 需人工选择
金额精度number 双精度BigDecimal 精确,double 有误差
数组原生数组List<T> / T[] 泛型集合
嵌套嵌套对象嵌套 POJO 或 Map
不可变性无概念record(Java 16+)或 final 字段
序列化开销低反射开销较大,可用编译期方案提速

边界条件

  • Long 与 Integer 的选择要看取值范围:毫秒时间戳必须用 long,用 int 会溢出成负数。
  • BigDecimal 反序列化时若 JSON 里是科学计数法字符串,部分库解析结果与原值不同,需配置精度策略。
  • 枚举字段遇到未知值时默认抛异常,生产环境通常要配置忽略未知枚举或映射为 UNKNOWN。
  • 循环引用对象序列化会栈溢出,需要配置忽略或使用 DTO 打断引用。

常见坑

  • 基本类型 int 接 null,反序列化直接抛 NPE 或解析失败。
  • snake_case 键没有注解映射,字段全部为 null 且不报错。
  • 金额用 double,累加误差导致对账差几分钱。
  • 毫秒时间戳用 int,2025 年的时间戳早已超出 int 范围,解析成负数。
  • JSON 里的 null 落到 Java 基本类型上会直接抛 NPE,只有包装类型(Integer、Long)才接得住,建模时按可空性选类型。

相关工具

常见问题

怎么把 Java 再转回 JSON?

使用同工具的交换方向功能,或本站对应的「Java 转 JSON」页面,两者都本地运行、数据不上传,可完成往返转换与校验。

JSON 和 Java 哪个更适合人类阅读?

这取决于场景:Java 通常更偏向程序解析与接口传输式的可读形态,而 JSON 更利于程序解析与接口传输式的程序消费;需要人工编辑时优先选可读性更高的那一侧。

生成的 POJO 用哪个 JSON 库?

通常是"不绑定库"的纯 POJO(字段 + getter/setter),由你决定用 Jackson、Gson 还是其它。这意味着 snake_case 的键不会自动映射——需要自己加 @JsonProperty("user_name")(Jackson)或 @SerializedName("user_name")(Gson)。

基本类型还是包装类型?

能确定非空就用 int/long,可能为 null 或字段可能缺失时必须用 Integer/Long,否则反序列化遇到 null 会抛 NPE 或直接失败。判断标准很简单:JSON 里这个字段允许 null 或允许不出现吗? 允许就用包装类型。