企业官网建设流程全解析

代码评审做得多了，你会发现一个很有意思的现象：方法引用（Method Reference）这个Java 8就有的语法，直到今天还是有两拨人在吵架。一拨人觉得x -> x.getName()已经够短够直白，非要写成User::getName是在炫技；另一拨人看到System.out::println就喜欢得不行，恨不得整个Stream管道全用双冒号连起来。两拨人说得都有道理，但我更关心的是另一件事：你确定自己真的会用方法引用吗？String::toUpperCase和s -> s.toUpperCase()完全等价的前提是什么？为什么Comparator.comparing(User::getAge)能直接传一个方法引用？方法引用和Lambda在字节码层面到底差在哪？

这篇文章不打算照着API文档念一遍就完事，而是把方法引用的四种形态、编译原理、与Lambda的等价边界、以及我在实际项目里踩过的坑一次说清楚。这篇内容比较长，适合刚接触Java函数式编程的读者，也适合已经写了几年Java但一直对方法引用细节含糊其辞的老手。全程用真实可跑的代码说话，能省的废话我都省了。

1. 为什么Java 8有了Lambda还不够，还要再补一个方法引用

1.1 Lambda的冗余表达是怎么产生的

Java 8引入Lambda表达式，解决了匿名内部类的一大痛点：语法太重。一个Runnable原来要写这么一坨：

Runnable r = new Runnable() { @Override public void run() { System.out.println("hello"); } };

用Lambda就变成了：

Runnable r = () -> System.out.println("hello");

但Lambda能解决的只是"少写样板代码"的一部分问题。仔细看() -> System.out.println("hello")这个Lambda：它做的事情其实就是"把零个参数传给一个已有的方法，让它去干活"。只要Lambda的方法体里只有一个方法调用，没有其他逻辑，那么这段Lambda本身仍然是多余的——你要说的其实就是"我要用System.out.println这个方法本身"。

换句话说，Lambda本质上是一种"把调用意图写出来"的语法，而方法引用是一种"直接把方法当作值进行传递"的语法。Java是纯面向对象语言，方法并不是一等公民，你不能像JS那样写const f = obj.method然后到处传。方法引用就是Java在语言层面补齐这个"方法即对象"能力的方式。

这里有一个关键认知，很多人到了面试时候才反应过来：方法引用不是Lambda的替代品，而是Lambda的一种语法糖。所有方法引用都能改写成等价的Lambda，但反过来，不是所有Lambda都能改写成方法引用。理解这一点，是避免在各种奇怪场景里硬套双冒号的前提。

1.2 可读性的真实收益和代价

从可读性角度讲，方法引用确实能让代码更干净。举个例子，从一个名单里取出所有人的姓名：

List<String> names = list.stream() .map(person -> person.getName()) .collect(Collectors.toList());

改成方法引用之后：

List<String> names = list.stream() .map(Person::getName) .collect(Collectors.toList());

第二版的可读性好在哪？它对读者的要求更低——不需要盯着Lambda参数person看它是怎么流进来的，只需要一眼看出"这个Pipeline干的是取name这件事"。

但方法引用也有代价：过度化简会丢失参数含义。map(String::toUpperCase)是一目了然的，但如果某个参数叫ctx而实际上被用作一个全局配置对象，写Context::getConfig就得让人回忆半天。所以我在代码评审里长期坚持一个标准：能一眼看出语义的用方法引用，需要看上下文才能反应过来的就用Lambda，绝不为了一行更短而牺牲实义。

2. 四种方法引用形态：难点从来不是语法，而是"谁调用谁"

2.1 静态方法引用：最没有争议的形态

ClassName::staticMethod是静态方法引用，也是四种形态里最容易理解的。Integer::parseInt等价于s -> Integer.parseInt(s)，Math::max等价于(a, b) -> Math.max(a, b)。函数式接口方法的参数按位置依次传给静态方法即可，没有"接收者"这个额外概念。

静态方法引用有一个我很常用的场景：配合filter做空值过滤和类型转换：

list.stream() .filter(Objects::nonNull) .map(String::valueOf) .collect(Collectors.toList());

Objects::nonNull这个引用非常典型：它接收一个参数、返回boolean，正好匹配Predicate<T>的test(T t)。函数式接口的签名匹配是方法引用能否成立的关键。静态方法引用只要保证"参数个数和顺序能对上，返回类型能对上"，剩下的就交给编译器推断。

写到这里必须提醒一句：静态方法引用也受重载决议影响。Integer::valueOf既有接收String的版本，也有接收int的版本，你把它赋给Function<String, Integer>时编译器选的是字符串版本，赋给IntFunction<Integer>时选的又是int版本。同一个方法引用，因为目标类型不同，解析出的是不同的重载，这点在你重构函数式接口类型时特别容易出幺蛾子。

2.2 绑定接收者的实例方法引用：instance::method

instance::method这种形式，方法引用在创建的时候就把"调用这个方法的对象"固定下来了。比如：

List<String> list = new ArrayList<>(); Consumer<String> c = list::add;

这里的list::add等价于s -> list.add(s)。这个接收者对象list在方法引用创建时就会被捕获，之后无论这个Consumer被传到哪、在哪个线程里执行，调用的都是同一个list的add方法。

我第一次用这个特性时踩过一个很隐蔽的坑：方法引用捕获的接收者是创建那一刻的引用，不是执行时的变量。也就是说，如果你在创建 Consumer 之后执行了list = new ArrayList<>()，已经创建好的 Consumer 内部持有的仍然是旧 list。这非常反直觉，因为平时我们写list.add(x)时，list是按当前变量动态解析的；而方法引用在创建时就完成了"绑定"，之后的变量变化跟它没关系。

另外一个容易踩的点是空指针。如果你用一个 null 对象去创建绑定方法引用，创建这个动作本身不会报错，但一旦调用这个 Consumer 的方法，就会立刻抛 NPE。原因是接收者虽然被捕获，真正的方法调用是在执行时才发生的，null 接收者在那个时刻才被检查。所以我在工具类里凡是暴露Consumer、Runnable这类回调的地方，都会在生成绑定时先做个防御性判空，避免把异常延迟到业务执行现场。

2.3 未绑定接收者的实例方法引用：ClassName::instanceMethod 是重灾区

这是四种形态里最容易让初学者混乱的一种。String::toUpperCase到底表示什么？它表示的是"把调用toUpperCase()方法的那个对象，作为参数传进来"。也就是说：

Function<String, String> f = String::toUpperCase; // 等价于 Function<String, String> f = s -> s.toUpperCase(); // 调用 f.apply("hello"); // 结果是 "HELLO"

这种形式对应的是：函数式接口方法签名中的第一个参数作为接收者，其余参数作为实例方法的参数。这也是为什么它叫"未绑定"——创建时并没有固定调用对象，真正的接收者在每次调用时才由第一个参数传进来。

理解这层关系之后，很多"为什么这个能直接传"和"为什么这里报错"的问题就迎刃而解。比如：

BiFunction<String, String, Boolean> b = String::startsWith; System.out.println(b.apply("abc", "a")); // true，等价于 "abc".startsWith("a")

startsWith本身只接收一个String prefix参数，但未绑定形式把函数式接口的第一个参数String当作接收者，第二个参数作为prefix，完美匹配。

更妙的例子是String::compareToIgnoreCase。它接收一个String参数，但当你把它赋给Comparator<String>时：

Comparator<String> c = String::compareToIgnoreCase; list.sort(c);

这等价于(a, b) -> a.compareToIgnoreCase(b)。注意这里的双参数映射：第一个参数a成为未绑定接收者，第二个参数b成为方法入参。所以一个接收单个参数的实例方法，经过去绑定之后，恰好能适配双参数的函数式接口。我当时搞明白这一点时，等于把Comparator相关的代码全部重写了一遍。

关于这个形态，网上流传最广的说法是"隐藏了第一个参数"。但我觉得更精确的理解是：这种形式表达的是"对传入对象的某个实例方法发起调用"，它把"接收者、参数"这个二元结构映射到了函数式接口的"第一个参数、剩余参数"。在Stream里，Stream.map(String::toUpperCase)之所以能工作，就是因为map接收的Function第一个参数就是流中的元素。你把这个映射关系理清了，以后见到任何未绑定引用都不会慌。

2.4 构造器引用与数组构造器：Class::new 的隐藏规则

构造器引用用ClassName::new表示。两个典型用法：

Supplier<ArrayList<String>> s = ArrayList::new; Function<String, File> f = File::new;

ArrayList::new匹配无参构造器，正好对应Supplier.get()。File::new匹配File(String)这个单参数构造器，对应Function<String, File>的apply。

这里有个重要细节：构造器引用的匹配规则和实例方法引用类似，完全根据目标类型来推断。同一个ClassName::new，赋给不同的函数式接口，会解析到不同的构造器。这是重载决议机制在起作用，构造器引用会参照函数式接口方法签名去选择匹配的构造器。

数组构造器引用是个容易被忽略的特例，语法是int[]::new：

IntFunction<int[]> arrayCreator = int[]::new; int[] arr = arrayCreator.apply(5); // 创建长度为5的int数组

这个形式在需要批量初始化数组、或者想避免循环里写new int[...]的场景下很好用。但要注意，数组构造器引用只能匹配一个接收int参数（表示长度）的函数式接口。你别想着用它来创建带初始值的数组，它做不到。而且反过来，如果你想用它充当Supplier<String[]>，编译会直接失败，因为数组创建表达式必须带长度参数。我曾经在给一个泛型工具类写默认数组工厂时踩了这个坑，IDE报错还提示得不清不楚，后来查文档才确认了这条规则。

还有一种构造器引用容易在泛型上翻车。Supplier<List<String>> s = ArrayList::new;是合法的，但要注意泛型在运行时已经被擦除，方法引用生成的实例运行时仍然是原始类型ArrayList。在一些涉及反射、JSON反序列化、泛型工具类的场景里，你一定要有这个意识，否则排查问题时会走很多弯路。

四种形态的匹配规律，我整理成一个表，方便在写代码时对照：

3. 方法引用背后的编译与运行机制：不是简单的"方法指针"

3.1 invokedynamic 到底做了什么

很多人在解释方法引用时说"方法引用就是把这个方法作为参数传过去"，这种说法停留在语义层面。实际上Java里把方法当作值传递，并不是真的把指向方法体的指针传来传去，而是通过invokedynamic指令配合LambdaMetafactory动态生成实现类。

Java 8引入Lambda和方法引用时，编译器并不会在编译期生成一个专门的匿名类——这一点和匿名内部类是完全不同的。编译器生成的是一条invokedynamic指令，加上常量池里的方法句柄（MethodHandle）信息。运行时首次执行到这条指令时，JVM会调用引导方法LambdaMetafactory.metafactory，去生成一个实现了目标函数式接口的实例，并且这个实例通常会做缓存，后续调用直接复用。

这个设计带来的直接好处是：方法引用没有"额外类加载"的开销，也没有匿名内部类每次创建都新建对象的成本。JIT编译器对通过 MethodHandle 生成的调用点有专门的内联优化，所以在热路径上，方法引用的表现往往优于手写的匿名内部类。

3.2 方法引用比Lambda更高明吗？并不会

我也见过另一种说法："方法引用 = 简化版的Lambda，性能更好"。从源码层面看，方法引用确实更简洁；从编译结果看，它和Lambda走的是同一套 invokedynamic 机制，并没有谁更高级。

区别只在于引导方法的入参：Lambda如果方法体里只是单方法调用，编译器同样有能力识别出来并归约为方法句柄；如果有额外逻辑，则要动态生成一个包含调用逻辑的Lambda类。也就是说，方法引用和Lambda在字节码层面的差异，通常比你想象的小得多。与其纠结"哪个性能更好"，不如把精力放在语义表达上。

我自己用 JMH 做过一个很粗糙的基准测试，在大量元素的排序场景下，方法引用比手写匿名Comparator的吞吐量大概高20%到30%，每次操作分配的内存也更少。但这个差距在绝大多数业务系统里根本感知不到，不要为了这点性能去硬改代码。它的真实收益还是在可读性上。

3.3 通过javap直观查看编译结果

为了让上面这些不显得太抽象，我们看一个极简例子，然后反编译：

import java.util.function.Function; public class Demo { public static void main(String[] args) { Function<String, Integer> f1 = String::length; Function<String, Integer> f2 = s -> s.length(); System.out.println(f1.apply("hello")); System.out.println(f2.apply("hello")); } }

编译后用javap -c Demo查看，你会发现两个赋值语句都被编译成invokedynamic指令，都指向常量池里的一个MethodHandle，引导方法都是LambdaMetafactory.metafactory。区别只是方法句柄描述符略有差异，整体结构几乎一样。所以String::length和s -> s.length()在这里是同一回事，知道这一点后再也不会被"方法引用更快"这种话带偏。

如果你用javap -v去看常量池，还会发现方法引用会记录一个NameAndType，里面包含方法名和描述符。方法引用的"引用"本质就是这样：它指向的是一个名称+类型签名，而不是某个对象在堆里的地址。这也是为什么一个方法引用能同时匹配多个重载——只要目标类型能定下来，它就能从同名方法中选一个匹配的。

4. 方法引用和Lambda的等价边界：哪些能套、哪些不能套

4.1 能等价改写的前提条件

能改写成方法引用的Lambda，最典型特征是"方法体里只有一个方法调用"，并且这个调用可以映射到函数式接口参数上。具体有三种常见模式：

• 静态调用：x -> Integer.parseInt(x)改成Integer::parseInt
• 实例调用，接收者是外部某个固定对象：x -> log.info(x)改成log::info
• 实例调用，接收者是函数式接口的第一个参数：x -> x.toUpperCase()改成String::toUpperCase

如果Lambda体里有两条以上语句、有分支、或对参数做了加工，方法引用就无能为力了。例如：

Function<String, Integer> f = s -> { if (s == null) return -1; return Integer.parseInt(s); };

这个Lambda没法直接用方法引用替换，因为它有判断逻辑。但你可以把判断逻辑抽到一个静态工具方法里，再引用那个方法——这也是一种常见的重构策略。把"不能改写的Lambda"变成"能被引用的方法"，既保留了逻辑，又让Stream管道保持干净。

4.2 参数个数与顺序错位的高频陷阱

方法引用最容易出错的地方，是函数式接口的参数顺序和方法自身参数的顺序对不上。说一个我在评审里见过不止一次的"想当然"：

// 想按字符串长度对list排序，有人会这样写 list.sort(String::length); // 编译报错 list.sort(String::compareTo); // 也不行

为什么String::compareTo不行？Comparator<String>的compare(String a, String b)接收两个参数，而String.compareTo只接收一个参数。通过未绑定机制，a会成为接收者，b会成为compareTo的参数，这样确实能组成(a, b) -> a.compareTo(b)。等一下，这其实是可以的，Comparator<String> c = String::compareTo;是合法的。真正要注意的是：String::length作为Comparator明显不对，因为length()无参，映射成(a, b) -> a.length()后b就悬空了，编译时参数个数不匹配，直接报错。

还有一类错位来自装箱拆箱。Integer::compare接收两个int基本类型参数，如果你把它用在Comparator<Integer>上没问题，因为泛型参数是Integer，自动拆箱对得上。但如果你用在Comparator<String>上就会编译失败，因为String和int之间不存在自动转换。方法引用不会帮你做任何参数转换或适配，参数类型必须能通过目标类型推断后精确匹配。

再看一个我实际踩过的坑。Comparator.comparing的签名是comparing(Function<? super T, ? extends U> keyExtractor)，你需要传一个把对象映射成排序键的函数。list.sort(Comparator.comparing(User::getAge))没问题，因为getAge无参，未绑定实例方法引用把User当第一个参数，返回Integer，正好匹配Function<User, Integer>。但是如果你想让User按姓名长度排序，可不要天真地以为能这样写：

list.sort(Comparator.comparing(String::length)); // 这是编译错误的

原因很简单：comparing需要的是Function<User, ...>，而String::length是Function<String, Integer>，User和String根本不是同一类型，编译器绝对不会让你过。这种情况下只能写Lambda：

list.sort(Comparator.comparing(u -> u.getName().length()));

或者给User加一个getNameLength()方法再引用。方法引用表达不了"先做一步转换再做一步映射"的组合逻辑，理解这个边界，比背语法重要得多。

4.3 重载与泛型带来的解析歧义

方法引用同样面临重载决议问题。以Collections.max为例，它有两个重载：

max(Collection<? extends T> coll) max(Collection<? extends T> coll, Comparator<? super T> comp)

当你写Collections::max，把它赋给：

BiFunction<Collection<Integer>, Comparator<Integer>, Integer> f = Collections::max;

编译器会去寻找第二个带Comparator参数的重载，因为目标类型BiFunction需要接收两个参数。而如果你把它赋给：

Function<Collection<Integer>, Integer> g = Collections::max;

编译器就会选择单参数版本。整个决议过程都跟着目标类型走。如果目标类型提供的参数模棱两可，编译器就会报"ambiguous method reference"错误。遇到这种报错，别跟编译器较劲，老老实实写Lambda就完了。

泛型方法引用也有类似问题。Class::method如果方法本身是泛型方法，目标类型给不出足够信息时，编译器可能推导出失真的类型参数，运行时通过桥接方法触发ClassCastException，报错位置在调用点，根因却在方法引用生成处。这种问题排查起来很费劲，我的建议是：凡是涉及复杂泛型推导的方法引用，先补一个显式的类型参数或中间变量，让类型一目了然。

5. 实战套路：Stream、比较器、Optional、事件回调里的方法引用

5.1 排序与比较器链

方法引用在Comparator里几乎成了标配。Comparator.comparing接收一个 keyExtractor 函数，天然适合方法引用：

list.sort(Comparator.comparing(User::getAge)); list.sort(Comparator.comparing(User::getAge).thenComparing(User::getName));

这种写法可读性极高，一眼就知道先按年龄排、再按姓名排。如果你需要处理 null，可以用：

list.sort(Comparator.nullsLast(Comparator.comparing(User::getAge)));

这里有个需要留意的细节：Comparator.comparing(User::getAge)默认要求 keyExtractor 的返回值是Comparable的。假如你写的是Comparator.comparing(User::getDepartment)，而Department这个类没有实现Comparable，编译器不会报错，但运行时排序会抛ClassCastException。所以要么让排序字段实现Comparable，要么手动给comparing传第二个参数：

list.sort(Comparator.comparing(User::getDepartment, Comparator.comparing(Department::getName)));

方法引用在这种嵌套比较器里依然能保持很强的可读性。

5.2 Stream管道里的典型组合

Stream 是方法引用出现频率最高的地方。几个高频写法：

list.stream() .filter(Objects::nonNull) .map(String::trim) .filter(s -> !s.isEmpty()) .map(String::toLowerCase) .forEach(System.out::println);

注意String::trim、String::isEmpty、String::toLowerCase都是未绑定接收者的实例方法引用，它们分别对应Function<String, String>和Predicate<String>。而System.out::println是绑定接收者的引用，因为System.out是一个固定的PrintStream对象。

另一个容易记混但实际很常用的写法是分组：

Map<Integer, List<String>> byLength = list.stream() .collect(Collectors.groupingBy(String::length));

String::length在这里充当Function<String, Integer>，作为 groupBy 的 keyExtractor 完美适配。返回值int会被自动装箱成Integer。

还要提醒一个并行流相关的问题：并行流里使用方法引用本身没有坑，但如果方法引用的接收者是一个共享的、非线程安全的对象，比如一个全局的SimpleDateFormat实例，写成df::format就非常危险。绑定引用看着优雅，实际上是把可变状态塞进了并行计算里。遇到这种场景，一定要改用局部变量或ThreadLocal，否则运行期会出现各种诡异的日期解析异常，复现还特别困难。

5.3 Optional、事件监听与回调里的写法

方法引用在Optional里也特别自然：

Optional.ofNullable(user) .map(User::getName) .filter(String::isEmpty) .orElse("unknown");

这里map(User::getName)把Optional<User>转成Optional<String>，filter(String::isEmpty)再过滤出姓名为空的场景，最后给出兜底值。整条链没有任何一处lambda参数需要理解，阅读成本非常低。

事件监听和回调场景同样如此：

button.addActionListener(this::onButtonClick); executorService.submit(this::doBackup);

this::方法名是绑定接收者的实例方法引用，它天然携带了当前对象this作为接收者。这里有个容易被忽视的点：this::onButtonClick会持有this的强引用。在GUI程序里，如果这个回调被注册到了生命周期很长的容器中，而this是一个应该被回收的界面对象，就会造成内存泄漏。这个风险和匿名内部类一样，并不是方法引用本身引入的新问题，但在写长生命周期的回调注册时，一定要留意引用链，该解绑的时候及时解绑。

5.4 自定义函数式接口与工厂模式

方法引用可以被用来实现轻量的工厂模式。比如定义一个抽象的创建器：

@FunctionalInterface interface Creator<P, T> { T create(P param); } Creator<String, File> fileCreator = File::new; Creator<String, User> userCreator = User::new;

把"构造过程"当作策略传来传去，在写多态创建、依赖注入、测试mock时非常实用。我维护过一个内部数据源管理组件，用Supplier<DataSource>做多个数据源的懒加载，每个 Provider 直接写成MysqlDataSource::new，比写一堆工厂类干净得多，替换数据源时也只需要改一行。

还可以配合Function做"参数映射 + 构造"的组合：

Function<String, File> resolver = path -> new File(baseDir, path);

这种场景Lambda比方法引用更合适，因为它确实有额外逻辑。选哪种并不取决于谁更高级，只取决于语义是否聚焦。

6. 面试与Code Review中的高频陷阱：这些坑我基本都踩过

6.1 绑定接收者 vs 动态查找变量的本质差异

面试里经常出现一道看似简单的问题：Function<String, String> f = String::toUpperCase;和Function<String, String> f = s -> s.toUpperCase();完全等价吗？答案是等价的，字节码层面也基本一致。

但追问一步：Consumer<String> c = System.out::println;和Consumer<String> c = s -> System.out.println(s);完全等价吗？这里就藏着区别了。System.out::println在创建时就捕获了当前System.out对象；而 Lambda 里写System.out.println(s)，每次执行时才会去解析System.out当前的值。如果在创建引用之后、调用之前执行了System.setOut(...)更换标准输出流，绑定引用仍然指向旧流，Lambda则会走向新流。这是"绑定接收者"和"动态查找变量"的本质差异，也是面试官考察你是否真正理解方法引用捕获机制时最爱埋的点。

这个差异在业务代码里能造成真实的线上事故。我经历过一个故障：一个日志组件在初始化时用this::write把写日志方法绑定到了某个文件通道上，后来配置热更新把文件路径改了，组件内部重建了通道并重新赋值给this.output，但因为回调已经绑定了旧的接收者，日志全部写进了旧文件。排查了好久才定位到是方法引用的绑定时机问题。所以在设计会热更新的组件时，回调要么用Lambda动态解析，要么确保重新绑定。

6.2 方法引用能在所有函数式接口场景下使用吗

不能。简答就是：方法引用只能替换"方法体是单方法调用、且参数可以映射"的Lambda。任何包含业务逻辑、分支、循环、局部变量的Lambda都无法直接改写。面试时记得举例子，比如x -> x.toUpperCase().trim()这种连续两次调用的Lambda就没法用方法引用替换，因为它是两个方法调用。

还有一类Lambda连"看起来像单方法调用"都算不上：需要对外部变量做修改的。比如：

AtomicInteger count = new AtomicInteger(); list.forEach(x -> count.incrementAndGet());

这里Lambda体里有副作用，方法引用也无能为力。所以方法引用的适用范围，本质上就是"纯转发调用"这一小类。把这句话记住，面试时能少踩很多坑。

6.3 数组构造器引用别用错目标类型

数组的构造器引用int[]::new只能匹配接收一个int参数的函数式接口。我在前面已经提过，它不能充当Supplier<String[]>。有些资料为了省事会说"数组引用就是构造器引用"，忽略了它必须带长度参数这个前提。实际使用中，IntFunction<int[]>是正确的目标类型，想要无参Supplier<String[]>请老老实实写() -> new String[0]。

还有一个相关但容易混淆的点：泛型数组不能用构造器引用直接创建。你不能写T[]::new这种形式，因为泛型数组在运行时类型不可确认。遇到需要运行时创建泛型数组的场景，仍然是走Array.newInstance这条路，方法引用帮不上忙。

6.4 Code Review中最常见的方法引用误用

在过去的评审记录里，我总结了几种高频误用，每一条基本都是真实案例：

1. 用绑定方法引用捕获可变对象。list::add作为Consumer存到全局回调里，对象的生命周期被意外拉长；或者因为捕获的是旧引用，行为与预期不符。凡是回调里可能涉及对象替换的，先想清楚要不要绑定。

2. 用方法引用隐藏副作用。obj::setValue这种写法把状态修改藏进了一行简洁代码里，阅读者如果不展开理解，根本意识不到这里有副作用。给 setter 做方法引用时，我一般会在代码评审里多问一句：这个副作用真的适合出现在这条调用链上吗？

3. 泛型方法引用的桥接问题。泛型擦除后，编译器会为方法引用生成桥接方法，某些场景下会引入隐藏的类型转换。方法引用一旦用错泛型参数，运行时ClassCastException就出现在调用点，而真正的原因却在方法引用的类型推导上。排查这类问题，第一步永远是回到方法引用的目标类型定义处检查。

4. 为了省Lambda而强行引用