java方法重载中，int与integer因自动装箱/拆箱易致“ambiguous method call”编译错误，根源是编译器匹配阶段无法唯一确定目标方法；应通过语义命名、显式转换或工具验证来消除歧义。
Java 方法重载中，int 和 Integer 虽然类型不同，但因自动装箱/拆箱机制，容易在调用时引发“ambiguous method call”编译错误。这不是语法问题，而是编译器在匹配阶段无法唯一确定目标方法。关键不是禁用装箱，而是让参数类型差异可分辨、调用意图可表达。
理解歧义发生的典型场景
以下情况会直接触发编译报错：
- 同时存在
void process(int x)和void process(Integer x)，调用process(null)→null既可赋给Integer，也可向上转型为Object（若还有process(Object)） - 同时存在
void handle(Number n)和void handle(Integer i)，传入字面量42→ 编译器先尝试精确匹配，int到Integer是装箱，int到Number是装箱+向上转型，两者转换成本不同但都可行，某些 JDK 版本下可能判定为歧义 - 泛型擦除后签名重复，例如
void log(List<string>)</string>和void log(List<integer>)</integer>→ 擦除后都是log(List)，编译不通过，根本不会走到装箱匹配阶段
优先用语义命名替代模糊重载
靠基本类型与包装类的微小差异区分重载，违背 Java 重载设计初衷。更健壮的做法是放弃同名，改用清晰动词：
- 把
save(int id)和save(Integer id)拆成saveById(int id)和saveByNullableId(Integer id) - 处理集合时，不用
process(List<string>)</string>和process(List<integer>)</integer>，而用processNames(List<string>)</string>和processIds(List<integer>)</integer> - 若逻辑高度复用，提取私有通用方法
private <t> void doProcess(List<t> list, Function<t string> formatter)</t></t></t>，对外只暴露命名明确的公有入口
必要时用显式转换破局
当重构成本高、必须保留现有重载时，最小侵入方式是控制编译时类型：
- 对
null实参，强制转型：process((Integer) null)或process((String) null) - 对字面量，避免依赖推导：
process(Integer.valueOf(100))明确走包装类路径；或用process((int) 100)强制走基本类型路径 - 方法引用场景下，不写
list.forEach(this::handle)，而写list.forEach((Integer x) -> this.handle(x))，让 lambda 类型信息锚定参数类型
借助工具快速验证候选方法
别靠猜，用 IDE 实时反馈定位问题根源：
- 将鼠标悬停在报错的方法调用处，IntelliJ 会列出所有候选方法，并标注 “why not applicable”，例如显示 “
Expected String, got Object” 说明泛型未推导成功 - 临时注释掉部分重载方法，观察是否只剩一个可选 —— 若能编译，说明冲突就在这几个之间
- 对泛型方法，执行
javap -s YourClass查看 descriptor，确认擦除后签名是否真重复；运行javap -c -v YourClass检查是否有桥接方法（含bridge和synthetic标记）意外参与重载解析
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
