方法引用在编译期生成强绑定的签名指纹，而非运行时对象：它依据目标函数式接口反向推导唯一匹配重载，固化为methodhandle等元数据，无闭包、无合成方法，确定性高、可静态验证。
方法引用在编译期不生成运行时对象，而是被解析为一个**可推导、可验证、与目标函数签名强绑定的编译期指纹**——它本质上是类型系统对“调用意图”的静态编码，而非对“某个具体函数地址”的硬编码。
指纹不是字符串，而是类型约束下的签名契约
Java 中 String::length 或 C# 中 list.Where 这类写法，在编译阶段就被绑定到唯一可匹配的重载候选上。编译器依据上下文目标函数式接口（如 Function<t></t>、Predicate<t></t>）反向推导参数数量、顺序、返回值及异常约束，最终确认一个不可歧义的签名。若存在多个重载且无法唯一确定（例如 Objects::toString 有 Object 和 int 两个版本），编译直接报错，不会“猜测”或延迟到运行时。
这个过程依赖的是：
- 目标函数式接口的形参列表与返回类型（即 SAM 类型的结构）
- 被引用方法的可见性、静态/实例属性、参数兼容性（含自动装箱/拆箱规则）
- 泛型类型实参的传递路径（如
List<string>::stream</string>中的T=String会参与推导）
编译器生成的底层表示：LambdaMetafactory 的输入元数据
Java 在字节码层面不保留“::”语法，而是通过 invokedynamic 指令触发 LambdaMetafactory 动态构建函数对象。但关键点在于：该指令的操作数栈上压入的，是编译期就固化下来的元数据，包括：
- 方法句柄（
MethodHandle）：指向已解析完毕的具体方法（非符号引用，已是解析后常量池索引） - 函数式接口的类型描述符（如
(Ljava/lang/String;)I） - 捕获变量的类型与个数（对实例方法引用，隐含第一个参数为接收者类型）
这些数据在 javac 输出 class 文件时就写死，运行时仅做轻量校验，不重新解析语义。
与普通 lambda 表达式的指纹差异
对比 s -> s.length()，方法引用的指纹更“紧凑”且“确定”：
- 无自由变量闭包逻辑（除非是绑定实例引用，如
obj::method，此时只捕获一个this引用） - 不生成额外的私有合成方法（synthetic method），避免了 lambda 表达式中常见的
lambda$xxx辅助方法 - 类型推导路径更短——无需从表达式体反推签名，而是正向从方法签名匹配接口
这种确定性使 JIT 在内联优化时更容易识别热点方法引用链，也便于静态分析工具（如代码图谱项目）准确建模调用关系。
跨语言印证：C# 与 Kotlin 的类似机制
C# 的方法组（method group）如 list.Add 在编译期同样经历签名绑定，生成 Delegate.CreateDelegate 所需的 MethodInfo 和类型参数；Kotlin 则将 String::trim 编译为 KFunction 实例的编译期常量引用。三者共性在于：指纹在 .class 或 .dll 输出那一刻就不可变，且与源码中书写形式解耦——改名方法但不改签名，指纹不变；签名微调（如加 throws），指纹立即失效。
