关键在于控制编译器能唯一确定调用路径：需显式声明实参类型、避免基本类型与包装类混搭重载、参数顺序不可互转、泛型静态方法勿依赖擦除后边界区分，必要时用类型令牌或工厂接口。
关键在于控制编译器能唯一确定调用路径，而不是单纯减少重载数量。Java 方法重载靠编译期类型匹配，歧义往往出现在自动类型提升、装箱拆箱、参数顺序模糊或泛型擦除等环节。
显式声明实参类型，堵住隐式转换入口
小整数字面量（如 1）默认是 int，'a' 默认是 char，但传给多个数值型重载时，编译器会尝试提升或装箱，导致多解。避免直接传字面量，改用变量明确类型：
- 需要调用 f(byte)？写 byte b = 1; f(b);
- 要走 f(char)？别用 f('a')，而写 char c = 'a'; f(c);
- 避免同时定义 f(int)、f(short)、f(byte) —— 编译器对 f(1) 有太多合法路径
不混搭基本类型与包装类重载
void handle(int x) 和 void handle(Integer x) 看似不同，但自动装箱规则会让编译器在两者间摇摆，尤其在方法引用或泛型上下文中极易报错：
- 同一语义操作，统一用基本类型（配合 IntConsumer 等专用接口）或统一用包装类
- 必须共存时，不用重载，改用不同方法名，比如 processRaw(int) 和 processBoxed(Integer)
- 慎用 Object 作兜底参数——它会让所有引用类型都“适配”，大幅增加歧义风险
参数顺序不同需确保类型不可互转
仅靠调换顺序构成重载，前提是两个位置的类型彼此无法隐式转换，否则编译器无法判断：
立即学习“Java免费学习笔记（深入）”；
- ✅ 安全：connect(String, int) 和 connect(int, String) —— String 和 int 不兼容
- ❌ 危险：add(int, double) 和 add(double, int) —— add(10, 20.0) 可能匹配任一，直接报 Ambiguous method call
- 调用时若出现歧义，可用强制类型转换临时解决，如 add((double)10, 20.0)，但这只是补救，不是设计原则
泛型静态方法重载要绕开类型擦除限制
泛型类型参数在编译后被擦除，导致 <T extends A> T foo() 和 <T extends B> T foo() 实际签名相同，编译失败：
- 不要依赖泛型边界区分静态重载方法
- 改用类型令牌（Class<T> 参数）传递运行时类型信息
- 或提取为工厂接口，由具体实现类承担类型特化逻辑
- 运行时需做类型判断时，用 instanceof 或 isAssignableFrom，但注意泛型变量本身不能用于 instanceof
