该用::而非lambda当且仅当lambda体仅调用一个已有方法且参数数量、顺序、类型完全对齐；否则语义错位或编译失败。
什么时候该用 :: 而不是 lambda？
方法引用不是语法糖的“装饰”，它是编译器在类型匹配成功时直接绑定已有方法的快捷路径。只有当 lambda 体只调用一个已有方法、且参数数量/顺序/类型完全对齐时，才适合换成方法引用——否则编译失败或语义错位。
- 常见错误现象：
myList.forEach(s -> System.out.println(s))可简化为myList.forEach(System.out::println)；但s -> s.toUpperCase().length()无法写成方法引用，因为涉及链式调用 - 使用场景：函数式接口（如
Consumer、Function、Predicate）参数与目标方法签名严格一致时最稳妥 - 参数差异：静态方法引用（
Class::staticMethod）不消耗接收者；实例方法引用分两种——obj::instanceMethod绑定固定对象，Class::instanceMethod把第一个参数当作隐式接收者（类似(obj, arg) -> obj.method(arg)）
String::compareTo 为什么有时报错？
看似简单的方法引用，实际依赖上下文推断出的函数式接口类型。如果编译器无法唯一确定目标接口，或者方法重载导致歧义，就会报 reference to compareTo is ambiguous。
- 常见错误现象：在
Comparator<string></string>场景下写String::compareTo没问题；但在泛型集合排序中若类型擦除导致T不明确，可能触发歧义 - 使用场景：仅适用于
Comparator<t></t>接口，且T必须是String或其子类；不能用于Function<string integer></string>，因为compareTo返回int但需要返回Integer - 性能影响：无额外开销，和直接调用字节码层级一致；但若误用导致编译失败，会拖慢开发节奏
构造方法引用 ArrayList::new 的限制
构造方法引用本质是把 new 操作符当成函数来用，但它只支持与目标函数式接口的抽象方法签名完全匹配的构造器。
- 常见错误现象：
Supplier<list>> sup = ArrayList::new</list>合法；但Function<integer list>> f = ArrayList::new</integer>要求存在ArrayList(int)构造器——而ArrayList确实有，所以合法；若换成HashMap::new配Function<integer map></integer>就不行，因为HashMap(int)构造器是public HashMap(int initialCapacity)，返回HashMap，类型不匹配 - 兼容性影响：Java 8+ 支持，但注意泛型构造器（如
MyClass<t>::new</t>）需确保类型参数能被推断，否则要显式写MyClass::<string>new</string>（Java 9+） - 容易踩的坑：数组构造器引用（
String[]::new）返回的是数组实例，不是集合，别和ArrayList::new混用
实例方法引用里 this 和 super 怎么处理？
this::method 是安全的，它捕获当前对象引用；但 super::method 有隐藏约束——只能在非静态方法中使用，且父类方法不能是 private 或默认包级私有（跨包不可见）。
立即学习“Java免费学习笔记（深入）”；
- 常见错误现象：在静态方法里写
super::toString直接编译失败，提示“non-static variable super cannot be referenced from a static context” - 使用场景：
super::method主要用在子类重写方法后，仍需在某个函数式接口中调用父类原始逻辑，比如自定义比较器中复用父类的equals - 底层映射：JVM 层面，
this::method编译为持有this引用的内部类实例；super::method则通过特殊字节码指令（如invokespecial）绕过动态绑定，所以不能用于接口默认方法
真正麻烦的是重载 + 泛型 + 类型推断三者叠加时的方法引用，这时候编译器往往不报具体哪一行错，而是笼统说“cannot resolve method reference”。遇到这种，先拆成 lambda 写清楚类型，再一步步缩回去。
