Java实战复盘：自动装箱藏着那些不起眼的空指针隐患

日常开发写代码，基本都会频繁用到基本类型和包装类互换。int、long、boolean 这类基础类型，搭配 Integer、Long、Boolean 使用，平时赋值、计算、传参，编译器自动帮我们完成装箱拆箱，体感上完全感知不到差异。
也正是因为太透明，很多人写代码完全不设防。默认包装类不会空、默认计算逻辑绝对安全，直到线上偶尔爆出空指针，定位代码一看，完全想不通这里为什么会空。
我之前处理过好几次线上偶发 NPE，既不是对象为空，也不是参数未校验，根源全是自动拆箱触发的隐性空异常。
最常见也最容易被忽视的场景，就是包装类直接参与数学运算。
业务代码里经常有数值累加、差值计算、倍率换算，很多人直接拿 Integer、Long 类型的字段去加减乘除。数据库字段允许为空、接口参数未传值、缓存取不到数据，都会导致包装类变量为 null。
编译阶段完全没问题，运行时一旦触发拆箱，直接空指针报错。
这种报错特别隐蔽，正常有值的情况下百分百正常运行，只有字段为空的边界场景才会炸。测试用例大多覆盖正常数值，很难复现，基本都是线上真实场景才暴露问题。
很多人习惯用包装类接收数据库可空字段，却沿用基本类型的计算逻辑，这是最大的问题来源。
还有一个坑点，是三目运算符引发的隐性装箱问题。
不少精简代码会用三目做默认值判断，一边写基本类型、一边写包装类型。编译器编译后会统一做自动装箱处理，整体变成包装类型。
看似简洁的代码，实际暗藏空值风险。一旦条件分支里出现 null 值，后续直接触发拆箱异常。很多人排查代码，看着逻辑完全没问题，怎么都想不到是三目语法导致的类型隐性转换。
缓存取值、RPC 返回值也是重灾区。
Redis、远程接口返回数值类型，大概率会出现 null 的情况。直接赋值给基本类型变量，会强制拆箱，瞬间抛出异常。
很多业务为了偷懒，不做 null 判断，直接强转、直接赋值、直接计算。本地测试缓存全是正常值，线上缓存过期、未命中、数据清空，瞬间触发批量报错。
还有一个细节，很多人分不清基本类型和包装类型的默认值差异。
基本类型有固定默认值，int 默认0、long 默认0L。包装类型默认全是 null。
实体类、DTO、缓存模型里的数值字段，绝大多数都用包装类。很多开发潜意识里觉得数值字段不可能为空，直接参与业务判断、金额计算、状态比对。
一旦遇到历史空数据、新业务未赋值数据，null 参与判断逻辑，会出现和预期完全不符的结果，甚至直接崩流程。
常年写代码慢慢发现，自动装箱拆箱是 Java 最温柔的陷阱。
编译器帮我们抹平了类型差异，提升了开发效率，却也让很多人忽略了空值风险。所有线上这类空指针，从来不是语法问题，都是编码习惯松散造成的边界漏洞。
现在我写数值逻辑，只要是包装类字段，但凡涉及计算、比较、赋值，一定会提前做空值兜底。不再依赖编译器自动转换，也不再凭直觉默认数值一定存在。
很多微小的语法细节，看着无关痛痒，恰恰是线上稳定性的关键。