自动装箱拆箱是编译器语法糖，由javac在编译期重写为valueOf()和intValue()调用；应通过正确使用、规避陷阱、统一规范来应对，而非自定义封装。
自动装箱和拆箱本身是编译器提供的语法糖，不是靠“封装”实现的，所以不存在通过自定义封装来隐藏其底层复杂性。它由 javac 在编译期直接重写代码，运行时就是普通方法调用（Integer.valueOf() 和 intValue()）。想“隐藏复杂性”，关键不在封装，而在**正确使用、规避陷阱、统一约定**。
避免暴露装箱/拆箱逻辑
不把包装类型当作“可选基本类型”随意混用，明确区分语义：
- 集合、泛型、API 参数/返回值中必须用
Integer等包装类 → 这是合理场景，无需隐藏，但需保持一致性 - 局部计算、循环变量、方法内部状态优先用
int等基本类型 → 减少隐式转换，性能更稳，null 风险归零 - 对外 API 若需支持 null（如数据库字段可能为空），返回
Integer；若业务上绝不为空，就用int并配 Javadoc 说明
用工具和规范拦截常见错误
靠人记不住所有坑，要靠机制提前发现：
java-api-doc-generator
下载
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
- 在 IDE 或 CI 中启用
SpotBugs或ErrorProne，它们能检测==比较包装类型、null 拆箱、循环中装箱等高危模式 - 团队代码规范明文禁止：不用 == 比较 Integer/Long 等包装类；强制用
Objects.equals(a, b)或a != null && a.equals(b) - 对可能为 null 的包装类型做拆箱前，统一走工具方法封装（非为“隐藏装箱”，而是集中防御）：
public static int safeIntValue(Integer i) { return i != null ? i : 0; }
理解缓存边界，不依赖意外行为
缓存（-128 ~ 127）是 valueOf() 的实现细节，不是语言契约。别把它当“特性”来用：
立即学习“Java免费学习笔记（深入）”；
- 不写
Integer a = 100; Integer b = 100; assert a == b;这类测试——它脆弱且误导新人 - 需要对象身份一致时，显式用
Integer.valueOf(x)并注释用途；需要值相等时，只用.equals()或比较基本类型 - 若业务真需小整数复用，可建自己的缓存池（如
IdCache.of(int)），语义清晰、范围可控、不耦合 JDK 实现
替代方案比“封装装箱”更治本
很多场景下，与其纠结怎么包装装箱逻辑，不如换更干净的抽象：
- 用 Optional
表达“可能存在”的整数值，把 null 意图显性化，避免拆箱爆炸 - 领域模型中，用专用值对象替代裸包装类，例如
UserId、Amount，内部封装int或long，提供安全的 getter（返回基本类型）和判空逻辑 - 数据库层用 MyBatis Plus 或 JPA 的 TypeHandler 统一处理 null ↔ 基本类型映射，业务代码里看不到 Integer
