Java自动装箱与拆箱不干扰方法重载解析本身，但显著影响编译器选择：重载分三阶段，装箱/拆箱仅在第二阶段启用；传入null或边界值易致歧义、编译失败或运行时NullPointerException。
Java 的自动装箱与拆箱本身不直接“干扰”方法重载，但它们会显著影响编译器选择哪个重载方法——尤其是在基本类型和包装类形参共存时，容易引发意料之外的匹配结果或编译错误。
重载解析分阶段，装箱拆箱只在后期介入
Java 编译器按三阶段解析重载方法：
- 第一阶段：只找**完全匹配**（参数类型一字不差），不启用装箱、拆箱或可变参数
- 第二阶段：允许**装箱/拆箱**，但禁用可变参数
- 第三阶段：才启用可变参数（含装箱/拆箱）
这意味着：如果存在 save(int id) 和 save(Integer id)，传入 save(123) 会直接命中 int 版本——根本不会触发装箱；但传入 save(null) 就无法匹配 int（基本类型不能为 null），只能退到第二阶段，尝试装箱，此时两个方法都“可行”，导致编译失败（ambiguous）。
常见歧义场景与表现
以下调用在有多个重载时极易出问题：
-
process(null)：若同时有process(String s)和process(Integer i)，编译器无法判定该装箱成哪个类型，报错“reference to process is ambiguous” -
process(100)：看似明确，但如果同时存在process(int)、process(long)、process(Integer)，而int又可被视作long（宽化）或Integer（装箱），优先级规则可能让结果偏离预期 -
list.forEach(this::handle)：方法引用若对应多个重载的handle（如handle(int)和handle(Integer)），编译器可能因上下文类型模糊而无法推导，报错
为什么缓存范围会让 == 比较更危险
当重载涉及 Integer 参数，又在方法内用 == 判断值是否相等时，缓存机制会放大风险：
javascript-typescript-typescript-scaffold
下载
你是 TypeScript 项目架构专家，专注于脚手架搭建生产就绪的 Node.js 和前端应用。生成包含现代工具链（pnpm、Vite、Next.js）、类型
-
Integer a = 127, b = 127; a == b→ true（同对象） -
Integer c = 128, d = 128; c == d→ false（不同对象）
这种不一致性在重载逻辑中若混用 == 和 .equals()，会导致行为随数值大小突变，极难排查。
null 拆箱是运行时陷阱，不是编译期问题
装箱解决的是“能不能调用”的问题，拆箱则埋下运行时雷：
- 方法签名是
void handle(Integer id)，内部写if (id > 0)—— 看似安全，但传入null时，编译器会自动插入id.intValue()，运行时抛NullPointerException - 这类错误不会在重载解析阶段暴露，只有执行到拆箱操作才崩溃
它不干扰匹配过程，却让“成功匹配”的方法在运行时意外失败。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
