java方法引用失败主因是类型不匹配，需严格比对函数式接口抽象方法与被引用方法的签名；对象引用可能空指针；泛型擦除导致推断歧义；方法引用绑定接口抽象方法而非实现类重写方法。
Java 方法引用写不成功，多数不是语法错了，而是类型没对上。它不是“看着像就能用”，而是编译器要严格比对函数式接口的抽象方法签名和被引用方法的参数个数、顺序、类型、返回值——差一点就报错。
函数式接口签名不匹配
这是最常遇到的编译错误，比如 error: incompatible types: invalid method reference。
- 静态方法引用（
Integer::parseInt）要求函数式接口抽象方法形如Integer apply(String)；如果接口是void accept(String)，就不行 -
String::compareTo可用于Comparator<string></string>，因为它的compare(String, String)和String.compareTo(String)参数顺序一致；但(a, b) -> b.compareTo(a)就不能简化为方法引用，参数顺序反了 - 别硬套
String::compareToIgnoreCase当Comparator，它语义上不满足严格偏序，排序可能出错；优先用String.CASE_INSENSITIVE_ORDER
实例方法引用对象状态失控
方法引用捕获的是对象引用，不是对象副本。一旦对象被置 null 或已出作用域，运行时就抛 NullPointerException。
-
obj::toString在Stream.forEach()或异步回调中很危险：如果obj是局部变量，方法执行时它可能已被 GC 回收 -
System.out::println安全，因为System.out是 static final，生命周期贯穿整个应用 - 稳妥做法：要么确保引用对象是强引用且生命周期覆盖执行时机，要么改用显式判空的 lambda，例如
x -> obj != null ? obj.toString() : "null"
构造器或任意对象方法引用类型擦除陷阱
泛型擦除会让编译器无法唯一推断目标类型，尤其在重载或模糊上下文中。
-
ArrayList::new可用于Supplier<list>></list>，但配Function<integer list>></integer>时，必须存在ArrayList(int)构造器，且返回类型得严格匹配 -
String::compareTo在泛型集合排序中若类型不明确（如T擦除后无法确定是String），会报reference to compareTo is ambiguous - 构造器带泛型时（如
MyClass<string>::new</string>），Java 9+ 才支持显式类型推导，否则需补全类型参数
误把默认方法当实现绑定
方法引用绑定的是函数式接口的**唯一抽象方法**，不是你写的那个同名方法。
- 写
a::myTest，而MyIF接口有抽象方法init()和默认方法myTest()，那这个引用实际是为init()提供实现，调用时执行的是接口默认版本，不是类里重写的myTest() - 这种行为不是 bug，是规范：方法引用永远绑定到函数式接口的抽象方法定义点，与实现类是否重写无关
- 想调用类中重写的方法？只能用 lambda 显式写
() -> a.myTest()，不能靠方法引用绕过接口契约
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
