函数式接口是方法引用的前提，其抽象方法与被引用方法必须在参数类型、返回类型、异常声明上严格一致；静态、实例、特定类型实例、构造器四类方法引用各有明确类型约束，类型不匹配将导致编译失败。
函数式接口本身不定义“引用类型”，但它的使用高度依赖引用类型的匹配——尤其是方法引用（::）能否成立，关键就看目标方法的声明是否与函数式接口的抽象方法在参数类型、返回类型、异常声明上严格一致。
函数式接口是方法引用的前提
只有当一个接口被设计为函数式接口（即仅含一个抽象方法），它才能作为方法引用的目标类型。比如：
-
Consumer
的 accept(String)要求被引用方法也接收一个String参数，且返回void -
Function
的 apply(Integer)要求被引用方法接收Integer、返回String -
Predicate
- >
test(List>)要求被引用方法参数为List，返回boolean
类型不匹配会直接编译失败，例如用 String::length 去实现 Consumer<string></string> 就不行——因为 length() 返回 int，而 accept 要求 void。
四类方法引用对应的引用类型规则
方法引用不是泛泛而谈的“调用方法”，而是按调用主体和签名特征分四类，每类对引用类型有明确约束：
-
静态方法引用（
Class::staticMethod）：要求该静态方法的形参列表和返回值，与函数式接口抽象方法完全一致。如Integer::parseInt可用于Function<string integer></string> -
实例方法引用（
instance::method）：实例对象类型必须能提供该方法，且方法签名匹配。例如new ArrayList<string>()::add</string>可用于Consumer<string></string> -
特定类型任意对象的实例方法（
Type::method）：方法属于某个类，但调用时以参数形式传入该类实例。如String::startsWith可用于BiPredicate<string string></string>（第一个参数是调用者，第二个是入参） -
构造器引用（
Class::new）：对应Supplier、Function等接口，要求构造器参数类型与接口抽象方法的参数类型一致，返回类型为该类。
常见类型适配陷阱
实际编码中，看似相似的类型常因泛型擦除或包装类差异导致引用失败：
-
int和Integer不可互换：若接口方法声明Function<integer boolean></integer>，就不能用Objects::nonNull（它接受Object），但可用Objects::isNull—— 因为Integer是Object子类，而泛型协变允许向上转型 -
Collection和List：若函数式接口要求Predicate<list>></list>，就不能直接引用Collection::isEmpty，除非显式转换或改用更宽泛的类型 - 数组类型特殊性：
String[]::new是IntFunction<string></string>，不是Supplier<string></string>—— 构造器引用的参数个数决定了它适配哪个函数式接口
如何快速验证引用是否合法
不必靠试错，三步判断即可：
- 查接口：确认目标接口是函数式接口，看清楚抽象方法的签名（参数类型、返回类型、是否抛异常）
- 查方法：确认被引用方法已存在，且声明的参数数量、顺序、类型，以及返回类型，与上一步完全一致
- 查上下文：确认引用表达式所在位置确实期待该函数式接口类型（如
stream().map(...)期待Function，而非Consumer）
满足这三点，方法引用就能安全使用，代码更简洁，语义也更清晰。
