java方法重载依赖编译期类型匹配，自动类型提升和装箱易引发歧义；应通过显式类型声明、避免基本类型与包装类混搭、限制object兜底及精确约束方法引用等方式确保匹配唯一性。
Java 方法重载本身不依赖运行时类型，而是靠编译器在编译期根据实参的编译时类型匹配签名。自动类型提升（如 byte → int、char → int）虽方便，但容易让多个重载方法都“看起来能接住”同一个实参，尤其在小整型字面量或 null 出现时，极易触发 reference to xxx is ambiguous 编译错误。避免这类歧义，关键不是禁用提升，而是控制匹配路径的唯一性。
明确实参类型，堵住提升入口
编译器对字面量（如 1、'a'）默认按最小兼容类型处理：1 是 int，'a' 是 char；但传给重载方法时，它会尝试提升匹配。若同时存在 f(int) 和 f(long)，调用 f(1) 没问题（精确匹配 int）；但若还有 f(Integer)，就可能因装箱+提升产生多义。
- 对字面量参数，显式声明变量并指定类型，例如：
byte b = 1; f(b);（强制走byte版本） - 避免直接传小整数字面量给多个数值型重载，比如不要同时定义
f(int)、f(short)、f(byte)——编译器会为f(1)提供太多可选路径 - char 类型要特别小心：没有
f(char)时，'a'会被提升为int；若同时有f(int)和f(Character)，f('a')就可能歧义
避开基本类型与包装类混搭重载
void handle(int x) 和 void handle(Integer x) 表面看是两种类型，但自动装箱规则会让编译器在两者间摇摆。尤其在方法引用（如 list.forEach(this::handle)）或泛型上下文中，目标类型模糊时，编译器无法确定该走原始类型路径还是装箱路径。
- 同一语义的操作，只保留一种风格：要么全用基本类型（搭配
IntConsumer、LongFunction等专用函数式接口），要么全用包装类 - 必须共存时，改用不同方法名，例如
processInt(int)和processObj(Integer)，从源头消除重载 - 慎用
Object作为兜底参数类型——它会让所有引用类型实参都“适配”，极大增加歧义风险
用精确的目标类型约束方法引用
方法引用（this::method）自身无类型信息，完全依赖接收方的函数式接口形参来反向推导。若接口形参是 Object 或未限定泛型（如 Consumer 原始类型），而类中又存在多个同名重载，编译器就无法抉择。
- 显式声明函数式接口变量，带具体类型参数：
Consumer<string> handler = this::handle;</string> - 在调用处用 Lambda 替代方法引用：
listOfString.forEach(s -> this.handle(s));——Lambda 主体明确指定了参数类型 - 静态方法引用可用强制转型指定目标接口：
(Predicate<string>) StringUtils::isBlank</string>，前提是该方法确实适配
优先级之外，别依赖“隐式”路径
Java 匹配顺序是：精确匹配 > 类型提升 > 装箱/拆箱 > 可变参数。但这不意味着你可以靠“它应该选第一个”来设计。一旦出现两个方法都在同一优先级层（比如一个 int、一个 Integer，对 int 字面量都是精确匹配层级），编译器就直接报错。
- 写重载时，主动检查每个实参可能的编译时类型，预判是否会产生多路径
- 测试时用典型字面量调用（
0、1L、null、'x'），而不是只测变量传参 - 对
null实参，永远显式转型：handle((String) null)或handle((Integer) null)，不留给编译器猜
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
