Java方法重载中自动装箱常引发歧义调用，应通过语义命名、显式类型转换和理解匹配优先级来规避，而非利用装箱；泛型擦除导致的假重载需改名或加限定解决。
Java 方法重载本身不“利用”自动装箱来防止选择错误——恰恰相反，自动装箱常是**引发选择错误（ambiguous method call）的根源**。关键不是去“利用”它，而是**控制它、规避歧义、让编译器能无歧义地选出最匹配的方法**。 下面从实践角度讲清楚怎么做：
明确区分意图：别靠 int 和 Integer 微小差异做重载
同时声明 process(int x) 和 process(Integer x) 看似类型不同，但编译器在面对字面量（如 process(5)）时会优先选 int 版本；而遇到 null 或泛型推导场景（如 list.forEach(this::process)），就可能无法判定，直接报错。
这不是设计缺陷，而是语言规则使然。真正健壮的做法是：
- 用语义命名替代同名重载：比如
processById(int id)和processByOptionalId(Optional<integer> id)</integer> - 若必须保留同名，就把包装类参数升级为更具体的语义类型（如
process(UserId id)，其中UserId是值类） - 避免把
Integer当作“可空的int”来重载，那是 API 设计信号混乱
控制实参类型：显式转换锚定匹配路径
当无法重构接口，又必须调用特定重载时，主动告诉编译器你要哪个版本：
- 传
null→ 写成process((Integer) null)或process((Object) null)，避免歧义 - 传字面量 → 用
process(Integer.valueOf(42))强制走包装类路径；或process((int) 42L)明确转为基本类型 - 方法引用 → 不写
list.forEach(this::handle)，改用list.forEach((Integer x) -> this.handle(x))，让 lambda 类型信息参与解析
理解匹配优先级：让编译器“不用猜”
Java 编译器选方法有固定顺序，不会“权衡”或“推测”：
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
- 精确匹配（类型完全一致）→ 最高优先
- 自动类型提升（
byte → int）→ 次之 - 装箱/拆箱（
int ↔ Integer）→ 再次之 - 可变参数（
...String）→ 最后兜底
所以，如果你写了 f(int)、f(Integer)、f(String...)，那么 f(100) 永远进第一个，f(new Integer(100)) 进第二个，f() 才进第三个。你不需要“利用”装箱，只需确保前两级（精确匹配、提升）能覆盖绝大多数常用实参。
警惕擦除和泛型假重载
泛型方法看似不同，但擦除后签名重复就根本过不了编译：
-
log(List<string>)</string>和log(List<integer>)</integer>→ 擦除后都是log(List)，编译失败 - 这不是装箱问题，但常被误认为类似歧义；解决方式是改名（
logNames(...)/logIds(...)）或加限定（log(List extends Number>)）
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
