方法引用需严格匹配函数式接口签名，否则编译失败；静态、实例、构造器引用各有参数和返回值约束；空安全需显式处理，否则运行时抛NPE；泛型擦除可能导致类型不兼容。
方法引用写成 :: 但编译不过？检查函数式接口是否匹配
方法引用不是语法糖的“随便写”，它本质是 Lambda 的简写，前提是目标类型必须是函数式接口，且被引用方法的签名（参数个数、类型、返回值）要和该接口的抽象方法完全兼容。
常见错误现象：error: incompatible types: invalid method reference 或 IDE 提示 “Method reference is not valid here”。
- 静态方法引用
String::valueOf要求函数式接口抽象方法形如String apply(int)—— 参数数量/类型必须和valueOf(int)一致，返回值也得是String - 实例方法引用
list::add中，list必须已存在（不能是 null），且接口方法签名得是boolean accept(String)这类单参数、返回boolean的形式 - 构造器引用
ArrayList::new对应的是Supplier<arraylist></arraylist>或Function<integer arraylist></integer>，取决于构造器参数个数
用 System.out::println 为什么有时输出 null？对象引用提前被 GC 或为空
方法引用捕获的是“当时那个对象的引用”，不是深拷贝。如果被引用的实例在后续执行时已被置为 null 或被 GC 回收，运行时就可能抛 NullPointerException，尤其在异步或延迟执行场景中。
使用场景：常用于 Stream.forEach()、CompletableFuture.thenAccept() 等延迟触发逻辑。
立即学习“Java免费学习笔记（深入）”；
你是 TypeScript 项目架构专家，专注于脚手架搭建生产就绪的 Node.js 和前端应用。生成包含现代工具链（pnpm、Vite、Next.js）、类型
-
list.forEach(System.out::println)安全，因为System.out是静态 final 实例，不会变 -
obj::toString危险：如果obj是局部变量且所在方法已返回，lambda 闭包里保存的只是原始引用，执行时obj可能已不可达 - 更稳妥写法：
x -> obj != null ? obj.toString() : "null"，或者确保obj是强引用且生命周期覆盖执行时机
Comparator.comparing(Person::getName) 报空指针？链式调用里没处理 null 值
方法引用本身不带空安全，Person::getName 在遇到 person == null 时直接炸，而 comparing() 默认不做 null 检查。
性能影响：加 null 处理会多一次判断，但比崩溃强；兼容性无问题，Java 8+ 都支持。
- 用
Comparator.nullsFirst(Comparator.comparing(Person::getName))让 null 排最前 - 用
Comparator.comparing(p -> p.getName(), Comparator.nullsLast(String::compareTo))更细粒度控制 - 避免写
Comparator.comparing((Person p) -> p.getName())—— 这不是方法引用，是 Lambda，失去了简洁性且没解决 null 问题
为什么 list.sort(String::compareTo) 编译失败？泛型擦除导致类型不匹配
String::compareTo 是实例方法，签名为 int compareTo(String)，但 List.sort() 要求 Comparator super E>，即参数类型需兼容 E。若 list 是 List<object></object>，编译器无法确认 Object 有 compareTo(String) 方法。
容易踩的坑：误以为“String 有 compareTo 就能直接用”，忽略了接收者类型和参数类型的双向约束。
- 对
List<string></string>，用String::compareTo没问题 —— 接收者是String，参数也是String - 对
List<object></object>，只能用(a, b) -> ((String)a).compareTo((String)b)或显式 cast - 更通用写法：
Comparator.naturalOrder()，它内部做了类型适配，且支持 null 安全
复杂点在于：方法引用的“隐式类型推导”依赖上下文，一旦泛型边界模糊或存在继承层级，编译器就容易卡住。别硬扛，换 Lambda 或工具方法往往更直白。
