java包装类本身可为null，必须主动防御；应配合optional.ofnullable、map/flatmap等链式操作安全处理，避免直接解箱或调用方法引发npe。
Java 中包装类型本身不能消除空指针异常（NullPointerException），但合理使用它们配合现代语言特性（如 Optional、非空断言、判空逻辑）能显著降低 NPE 风险。关键不在于“用包装类型就能避免空指针”，而在于**意识到包装类型天然可为 null，必须主动防御**。
别直接调用包装类型的实例方法
Integer、Long、Boolean 等包装类是引用类型，变量可能为 null。一旦解包（如自动拆箱）或调用其方法（如 .intValue()、.equals()），就可能触发 NPE。
- ❌ 错误写法：
Integer count = null; int i = count.intValue();→ 抛出 NPE - ❌ 危险写法：
if (flag.equals(true))（flag 是 Boolean 类型且为 null）→ NPE - ✅ 安全写法：
if (Boolean.TRUE.equals(flag))或if (flag != null && flag) - ✅ 更推荐：
Objects.equals(flag, true)（处理 null 安全）
优先用原始类型参数 + 显式判空
方法入参尽量用基本类型（int、boolean 等），迫使调用方提供有效值；若必须接收包装类型（如 JSON 反序列化、数据库映射），应在入口处立即校验并转换：
- 用
Objects.requireNonNull()明确拒绝 null（适合不允许为空的场景） - 用
Objects.nonNull()+ 默认值兜底：int value = num == null ? 0 : num; - Spring 或 Lombok 可借助
@NonNull注解 + 编译期/运行期检查（需配套工具支持）
善用 Optional 封装可能为空的包装类型
Optional 不是为替代 null 而生，而是**显式表达“可能没有值”这一语义**，强制调用方处理空情况：
- 不要把 Optional 作为字段或返回 null 的“遮羞布”——它不该持久化或被滥用
- 正确用法示例：
Optional<integer> optId = findId(); optId.orElse(0);</integer>或optId.ifPresent(this::process); - 与包装类型结合时，避免
Optional.of(null)（会立即抛 NPE），改用Optional.ofNullable(num)
统一规范：API 设计阶段就约定 null 含义
比编码技巧更重要的是团队协作规范：
- 接口文档明确标注哪些参数/返回值可为 null，哪些不可
- DTO、VO 层字段加
@NotNull/@Nullable注解（IDE 和静态检查工具可预警） - 数据库字段设为 NOT NULL，配合 MyBatis-Plus 等框架自动映射为基本类型，从源头减少 null
- 日志中打印包装类型值前先判空，避免
log.info("id={}", id)因 id==null 导致 toString() 异常（虽 log 框架通常防护，但仍建议谨慎）
不复杂但容易忽略：包装类型是 null 安全的“假象”，真正安全来自设计意识 + 主动检查 + 工具辅助。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
