应统一使用包装类声明所有可空字段，显式判空并禁用隐式拆箱，金额用bigdecimal、时间戳用instant或long、id用long或string，序列化层需加范围校验与失败日志。
在分布式传输中，Java 基本类型与包装类的混用不是语法问题，而是数据契约断裂的起点。核心矛盾在于：基本类型无法表达 null，而网络通信天然存在缺失、可选、未赋值等语义；包装类虽支持 null，但自动拆箱又埋下 NPE 隐患。防错的关键不是“避免用哪个”，而是统一规则 + 显式边界 + 协议对齐。
统一用包装类声明所有可空字段
JSON、Protobuf 或 Avro 中，字段默认可为空（如 JSON 的 "age": null）。若 Java DTO 中定义为 int age，Jackson 默认拒绝反序列化，报错或静默跳过；若分支逻辑中部分子类用 int、部分用 Integer，则同一字段在不同服务路径下行为不一致。
- 所有数值、布尔型字段一律使用
Integer、Long、Boolean等包装类，禁用int、boolean - 特别检查继承结构、策略模式、多版本 DTO（如 v1/v2 接口共用类），确保同名字段类型完全一致
- 如必须保留基本类型（如性能敏感内部缓存），需显式配置反序列化策略：
@JsonSetter(nulls = Nulls.SKIP)或@JsonSetter(defaultValue = "0")
禁用隐式拆箱，所有读取先判空
看似安全的 if (user.getAge() != null && user.getAge() > 18)，一旦 getAge() 实际返回 int（已拆箱），null 判空就失效；更危险的是 int age = user.getAge(); —— 若 user 是反序列化失败对象，该行直接抛 NullPointerException，且堆栈指向业务代码而非解析层，极难定位。
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
- 所有从反序列化对象读取的包装类字段，在参与比较、计算、传参前，必须显式判空：
Objects.nonNull(user.getAge()) && user.getAge() > 18 - 禁止在
if、switch、算术表达式中直接使用包装类变量（如user.getAge() + 1） - IDE 中启用「boxing/unboxing inspection」，高亮潜在自动拆箱点
敏感字段强制语义化类型
金额、时间戳、ID 这三类字段，基本类型与包装类的差异会放大为业务错误。例如 double price 在 JSON 中转成字符串后精度丢失；long orderId 被反序列化为 Integer 导致溢出；int timestamp 存不下毫秒级时间戳。
- 金额统一用
BigDecimal（字符串传值），禁用float/double - 时间戳统一用
Instant或Long，禁止int；JSON 中固定为 ISO-8601 字符串格式 - ID 类字段统一用
Long或String（避免数据库自增超限或分库分表 ID 冲突） - OpenAPI 规范中明确定义：
type: integer, format: int64→ 对应 JavaLong；type: number, format: double→ 对应Double
序列化层加守卫与日志
光靠编码规范不够，要在框架层拦截典型错误。例如收到 {"timeoutMs": 3000000000}（超 21 亿），用 (int) jsonNode.get("timeoutMs").asLong() 会静默溢出为负数，降级逻辑彻底失效。
- 在反序列化入口（如 Spring @RequestBody 处理器、Kafka 消费者 handler）添加字段范围校验：对
timeoutMs设置合理上限（如Math.toIntExact()替代裸强转） - 对关键字段开启 Jackson 的严格数字解析：
DeserializationFeature.FAIL_ON_NUMBERS_FOR_ENUMS、FAIL_ON_NULL_FOR_PRIMITIVES - 记录反序列化失败时的原始 JSON 片段和字段路径，便于快速复现和归因
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
