方法引用在重载场景下易产生编译期歧义，因引用本身无类型信息，必须依赖目标函数式接口的参数类型精确匹配；若接口形参模糊（如Object或未限定泛型），多个重载方法均可能适配，导致ambiguous reference错误。
当方法引用（如 :: 表达式）出现在函数式接口上下文中，而目标类型存在多个重载方法时，Java 编译器可能无法唯一推导出应绑定哪个重载版本——这不是运行时错误，而是编译期“歧义”（ambiguous reference）。这种冲突不靠肉眼判断，而依赖编译器对函数式接口形参类型的反向匹配。关键在于：**方法引用本身不携带类型信息，必须由接收方（目标函数式接口）提供足够约束**。
明确目标函数式接口的参数类型
编译器靠目标类型（即 Lambda 或方法引用要赋给的函数式接口）来缩小候选方法范围。如果接口形参类型模糊（比如是 Object 或泛型未限定），多个重载方法都可能“适配”，就会报错。
- ✅ 正确做法：显式声明变量类型或使用带类型参数的接口实例
// 假设有两个重载方法
void handle(String s) { }
void handle(Integer i) { }
// ❌ 编译失败：List.forEach 接收 Consumer<T>，但 T 是 Object，两个 handle 都可接受
list.forEach(this::handle);
// ✅ 显式指定 Consumer 类型，约束参数为 String
Consumer<String> stringHandler = this::handle;
listOfString.forEach(stringHandler);
// ✅ 或直接在 forEach 中用 Lambda 消除歧义（更常见）
listOfString.forEach(s -> this.handle(s));
避免用基本类型/包装类混搭重载
像 void m(int) 和 void m(Integer) 这类重载，在方法引用中极易触发歧义。因为自动装箱/拆箱规则会让编译器在 Consumer<Integer> 和 IntConsumer 等不同目标类型间摇摆不定。
- 优先只保留一种：要么全用基本类型（配合专用函数式接口如
IntConsumer），要么全用包装类型 - 若必须共存，改用不同方法名（如
handleInt()/handleObj()），彻底避开重载
用静态方法引用 + 明确类型转换
对静态方法引用（ClassName::methodName），可借助强制类型转换显式告知编译器目标函数式接口：
// 假设 StringUtils 有： // static boolean isBlank(String s) // static boolean isBlank(CharSequence cs) // ❌ 模糊：CharSequence 和 String 都匹配 Predicate<String> Predicate<String> p = StringUtils::isBlank; // ✅ 强制转成接受 String 的版本 Predicate<String> p = (Predicate<String>) StringUtils::isBlank;
注意：该转换仅在只有一个重载方法签名与目标接口完全兼容时才有效；否则仍报错。
封装为专用函数式接口或适配器
当重载逻辑本质不同（比如一个处理 ID 字符串，一个处理原始数字），与其强行让编译器猜，不如主动隔离：
- 定义语义清晰的函数式接口：
interface UserIdHandler { void accept(UserId id); } - 或写一个轻量适配器方法：
private Consumer<String> stringHandler() { return this::handle; }，再引用它
这既消除了歧义，又提升了调用端的可读性——谁都能看出这个引用专用于字符串场景。
