结论：业务歧义常源于字段语义被默认值覆盖，int age=0与integer age=null在业务中含义截然不同；基本类型有强制默认值（如0、false），包装类默认null，分别表示“有效值”与“缺失”，混用会导致“未填”与“明确为零”无法区分。
直接说结论：业务歧义往往不是逻辑写错了，而是字段语义被默认值悄悄覆盖了——int age = 0 和 Integer age = null 在业务上完全不是一回事，但代码里一混用，系统就分不清“用户没填年龄”和“用户年龄是零岁”。
看清默认值背后的业务含义
基本类型有强制默认值（int 是 0、boolean 是 false），包装类默认是 null。这在业务中意味着：
- 0 或 false 可能是有效业务值：比如商品库存为 0、开关状态为 false，都是明确意图；
- null 表示“缺失”或“未设置”：比如用户未填写年龄、订单未确认支付、配置项未启用。
一旦在同一个 DTO 或 Entity 中混用 int status 和 Boolean enabled，JSON 里缺字段时：status 得到 0（可能被当成“已关闭”），enabled 却是 null（表示“状态未知”）——同一笔数据，两个字段表达的确定性完全不同。
检查分支与多态场景下的类型一致性
策略模式、工厂模式或 if-else 分支中，不同子类/分支对同名字段使用不同类型，最容易埋雷：
- 父类定义
Boolean isVerified，子类 A 改成boolean isVerified，反序列化时若 JSON 缺该字段，父类对象 isVerified = null，子类对象 isVerified = false ——业务校验逻辑可能一个走“待审核”，一个直接放行； - v1 接口用
long version，v2 升级为Long version，旧客户端不传 version 字段，新服务反序列化后得到 0（而非 null），版本比对逻辑误判为“v0”。
重点扫描所有继承链、接口实现类、DTO 复用场景，确保同名业务字段类型统一（推荐全用包装类）。
堵住自动拆箱带来的静默误判
看似安全的判断，可能因拆箱把 null 变成默认值，掩盖真实状态：
-
if (user.getAge() > 18)：如果 getAge() 返回 Integer 且为 null，此处会 NPE；但如果返回的是 int，就永远是0 > 18 == false，逻辑跳过——你根本不知道这个用户年龄缺失； -
status.getCode() == 200：getCode() 返回 Integer，null 拆箱崩；若改成基本类型 int getCode()，那没赋值时就是 0，等于永远不等于 200，错误被掩盖。
凡是涉及比较、计算、条件判断，优先用 Objects.equals(a, b) 或显式判空：age != null && age > 18，别依赖自动行为。
用配置和工具把歧义挡在上线前
光靠人盯容易漏，得靠机制兜底：
- Jackson 配置全局策略：
mapper.setDefaultSetterInfo(Nulls.SKIP)或为关键字段加@JsonSetter(nulls = Nulls.FAIL)，让缺失字段直接报错，而不是默默给默认值； - IDE 开启 “Unboxing of a null value” 检查，高亮所有潜在拆箱点；
- DTO 层加 Lombok
@Getter(onMethod_ = @NonNull)或字段级@NotNull，配合 Hibernate Validator 在入参时拦截 null 包装类（尤其对必填业务字段）； - 数据库映射层，对不允许为空的字段设
@Column(nullable = false)，避免 ORM 把 null 写成 0 后再读出来造成混淆。
业务字段一旦涉及“可选”“未设置”“暂无”，就别用基本类型——不是不能用，而是它天然不具备表达“缺失”的能力。用包装类 + 显式空处理，才能让代码说出你想表达的真实意思。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
