方法引用与泛型方法结合，本质是用类型安全的方式分离“做什么”和“对谁做”；关键在于回调自动适配类型且保持可读性与编译检查，需泛型参数出现在签名中、函数式接口严格对齐，并通过边界约束提升安全性。
方法引用与泛型方法结合，本质是用类型安全的方式把“做什么”（逻辑）和“对谁做”（数据类型）分开。关键不在语法炫技，而在让回调既能自动适配不同入参/返回类型，又不牺牲可读性和编译检查。
泛型方法定义要暴露类型契约
回调的通用性始于方法签名的设计。泛型参数必须出现在参数或返回值中，否则编译器无法推断；同时，方法引用依赖的函数式接口需与泛型方法严格对齐。
- 定义泛型回调接口时，明确输入、输出类型：例如
@FunctionalInterface interface Action<t r> { R execute(T input); }</t> - 通用方法接收该接口，并声明完整泛型：例如
public static <t r> R runWithLog(T data, Action<t r> action)</t></t> - 调用时无需写
<string integer></string>，传入String::length就能自动推断T=String, R=Integer
方法引用需匹配泛型上下文
不是所有方法引用都能直接用于泛型回调——它必须满足签名兼容性。编译器根据泛型方法参数类型反向约束方法引用的目标方法。
- 静态方法引用：如
Integer::parseInt可用于Action<string integer></string>，因为parseInt(String)入参出参完全匹配 - 实例方法引用：如
"hello"::startsWith是Action<string boolean></string>，但若泛型方法期望Action<object boolean></object>，则不兼容（类型不协变） - 构造方法引用：如
ArrayList::new对应Action<collection list></collection>，常用于工厂类泛型回调
组合泛型边界提升业务安全性
当回调涉及领域对象操作时，单纯 <t r></t> 不够。加入泛型边界，让方法引用在编译期就受约束，避免运行时转型失败。
- 例如定义
public static <t extends user r> R process(T user, Function<t r> handler)</t></t> - 此时只能传入
User::getName或Admin::getRole（前提是Admin extends User），而不能传String::length - 边界确保方法引用调用的目标方法存在于
T及其子类中，逻辑更内聚
避免类型擦除干扰实际场景
泛型方法本身不保留运行时类型，但方法引用绑定的是具体类的方法。只要泛型方法不依赖 Class<t></t> 做反射，二者就能天然协同。
- 常见陷阱：在泛型方法内部试图用
T.class获取类型——这会报错，因T已被擦除 - 正确做法：若需运行时类型（如 JSON 反序列化），应额外传入
Class<r></r>参数，与方法引用解耦 - 方法引用只负责行为，类型信息由泛型方法参数承担，职责清晰，不易出错
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
