Java方法重载仅依据参数列表，但自动装箱、泛型擦除等可能导致ambiguous method call；应优先用语义化方法名替代易歧义重载，必要时显式指定类型或改用运行时分发。
Java 方法重载本身不依赖返回类型或修饰符，只看参数列表。但当存在自动装箱、向上转型、泛型擦除或函数式接口目标类型模糊时，编译器可能无法唯一确定调用哪个重载方法，从而报 ambiguous method call 错误。避免这类歧义，关键不是禁用语言特性，而是让调用意图清晰、类型边界明确。
优先用语义化方法名替代易歧义的重载
靠 int 和 Integer 的细微差异区分重载，既难维护又易出错。更直接的方式是放弃同名，改用动词+语义后缀：
-
saveById(int id)与saveByOptionalId(Optional<Integer> id)—— 明确表达是否允许空值 -
parseAsNumber(String s)和parseAsPath(String s)—— 避免仅靠String类型承载多种含义 - 集合操作不用
process(List<String>)和process(List<Integer>)，而用processNames(...)与processIds(...)
必要时用显式类型控制编译期推导
当重构成本高、必须保留现有重载时，最小改动是让实参的静态类型“说话”：
- 对
null：写handle((String) null)或handle((Integer) null)，强制指定目标类型 - 对字面量：用
handle(Integer.valueOf(42))明确走包装类路径；或handle((int) 42L)强制走基本类型 - 方法引用场景：不写
list.forEach(this::handle)，改用list.forEach((String s) -> this.handle(s))，让 lambda 的形参类型锚定重载选择
避开高风险重载组合
以下模式在多数 JDK 版本中极易触发歧义，应主动规避：
立即学习“Java免费学习笔记（深入）”；
-
void m(int)与void m(Integer)——null、字面量、方法引用均可能失败 -
void m(Number)与void m(Integer)—— 字面量42可同时匹配（装箱→Integer，或装箱+向上转型→Number） -
void log(List<String>)与void log(List<Integer>)—— 泛型擦除后签名重复，编译直接失败，根本不会进入装箱匹配阶段 - 多个接受
Callable<V>的重载方法 —— 若仅靠返回类型V区分，编译器无法推断，应改用不同方法名如submitStringTask()、submitIntTask()
用运行时类型分发补足编译期限制
当泛型约束（如 <T extends CharSequence> 和 <T extends Temporal>）与实参静态类型（如 Comparable）不兼容时，编译器无法自动选择：
- 不要依赖泛型重载自动适配，改用
instanceof分支手动调度 - 例如：先判断
value instanceof LocalDate，再调用对应专用方法；比泛型重载更可靠、更易读 - 这种写法也避免了因类型擦除导致的桥接方法冲突问题
