方法引用是lambda表达式的精简写法，适用于已有方法签名完全匹配函数式接口的场景；静态、实例、构造器引用分别对应不同调用形式；仅当lambda仅转发调用且方法语义清晰时才应替换。
方法引用不是 Lambda 表达式的替代品，而是它的精简写法——当已有方法恰好匹配函数式接口的抽象方法签名时，就该优先用方法引用。
看有没有现成方法可复用
方法引用的核心前提是：你 already 有一个符合参数类型、返回值和异常声明的方法。比如：
-
静态方法引用：
String::valueOf替代x -> String.valueOf(x) -
实例方法引用（对象已存在）：
list::add替代x -> list.add(x) -
实例方法引用（对象未定，靠入参提供）：
String::length替代s -> s.length() -
构造器引用：
ArrayList::new替代() -> new ArrayList()
只要这个方法逻辑清晰、命名准确、无副作用，方法引用一写出来，语义就比 Lambda 更直白。
看 Lambda 是否只剩“调一个方法”的壳
如果你写的 Lambda 表达式只做一件事：把参数原样传给某个方法，并返回结果，那它大概率可以被方法引用替代。
例如：
-
str -> str.toUpperCase()→ 直接换成String::toUpperCase -
obj -> obj.toString()→ 换成Object::toString -
n -> Math.abs(n)→ 换成Math::abs
一旦 Lambda 里出现条件判断、多个语句、临时变量或额外计算，就不能用方法引用了——它不支持逻辑展开，只认“直接转发”。
看可读性和维护成本
方法引用更像“说名字”，Lambda 更像“说动作”。选哪个，取决于谁更容易理解。
- 用
System.out::println比x -> System.out.println(x)更紧凑，也更明确表达“就是打印” - 但
user -> user.isActive() && user.getScore() > 80就没法用方法引用，硬套反而绕弯 - 如果方法名本身含糊（比如叫
process()），不如写清楚逻辑的 Lambda 来得安全
别为省字符而牺牲意图表达
方法引用虽短，但前提是它能准确传达意图。如果引用的方法做了多件事、有隐藏状态、或语义模糊，强行使用反而降低可读性。
例如：
-
User::save看似简洁，但如果save()内部还触发邮件、更新缓存、抛异常，那users.forEach(User::save)就容易让人误判行为边界 - 此时写成
user -> user.save()或加注释，反而更稳妥
本质上，方法引用是“已验证行为”的快捷入口；Lambda 是“即兴逻辑”的轻量载体。按需选用，不强求统一。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
