函数式接口与方法引用天然一体：方法引用必须置于函数式接口上下文中，由其抽象方法签名校验合法性；四种引用形式分别精准适配不同接口场景，替换Lambda仅当参数、返回值完全吻合时才实现语义精简。
函数式接口与方法引用不是“搭配使用”的技巧，而是天然一体的设计：方法引用必须作用于函数式接口定义的抽象方法签名，而函数式接口为方法引用提供了类型契约和上下文。关键不在“怎么结合”，而在“为什么能无缝结合”以及“怎么用得准确”。
函数式接口是方法引用的唯一容器
方法引用（::）本身没有类型，它必须被赋值给一个函数式接口类型的变量，或作为参数传入接收该接口的方法中。编译器靠函数式接口的抽象方法签名来校验方法引用是否合法。
- 比如
System.out::println能用于Consumer<String>，是因为它的accept(String)方法签名与println(String)完全匹配 - 但不能直接赋给
Function<String, Integer>，因为println不返回Integer，也不符合apply(String)的契约 -
@FunctionalInterface注解不是摆设——它让编译器在接口定义层就守住这个契约底线
四种方法引用形式对应四类函数式接口场景
每种引用形式背后，都隐含着对函数式接口抽象方法参数/返回值结构的精准适配：
-
静态方法引用（
ClassName::staticMethod）：适合Function、Predicate、Supplier等需要“输入→输出”或“无参→结果”的场景。例如Integer::parseInt可直接作为Function<String, Integer> -
实例方法引用（
obj::instanceMethod）：适用于已持有对象实例、且需复用其状态的场景，如list::add作为Consumer<E> -
任意对象的实例方法引用（
ClassName::instanceMethod）：最易混淆也最有价值。它把第一个参数“当作调用者”，自动补上前置接收者。例如String::length匹配Function<String, Integer>，等价于s -> s.length() -
构造器引用（
ClassName::new）：专为Supplier、Function、BiFunction等带泛型参数的接口设计。如ArrayList::new可赋给Supplier<List<String>>或Function<Integer, List<String>>（取决于构造器重载）
真正“完美结合”的标志：不写 Lambda，也不改逻辑
当你发现某个 Lambda 表达式只做一件事——调用一个已有方法，且参数顺序、数量、类型、返回值完全吻合，那它就是方法引用的“自然候选”。此时替换不是为了炫技，而是消除冗余语义：
Java注释规范Skills
下载
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
立即学习“Java免费学习笔记（深入）”；
- ❌
str -> str.toUpperCase()→ ✅String::toUpperCase - ❌
s -> System.out.println(s)→ ✅System.out::println - ❌
() -> new HashMap<>()→ ✅HashMap::new
这种替换不改变行为、不新增抽象、不引入新对象，只是让代码回归到“调用什么”这个本质，而不是“怎么包装成函数”。
容易踩坑的兼容性细节
看似简单的 ::，实际依赖严格的签名推导。常见问题包括：
- 泛型擦除导致的类型不明确：如
list::remove有多个重载，需显式指定函数式接口类型（如Consumer<String>或BiPredicate<List<String>, String>）才能消歧 - 实例方法引用中隐式参数位置：对于
String::startsWith，它匹配的是BiPredicate<String, String>，第一个String是调用者，第二个是参数 - 默认方法和
Object方法不参与匹配：接口里写了default toString()，不会影响Function::apply对方法引用的解析
