让我来谈谈为什么我们在语言中添加了这个特性，而我们显然不需要（所有方法refs都可以表示为lambdas）
请注意，没有正确的答案。任何说“总是使用方法引用而不是lambda”或“总是使用lambda而不是方法引用”的人都应该被忽略。
这个问题在精神上非常类似于“何时应该使用命名类与匿名类”？答案是一样的：当你发现它更具可读性时。当然，有些案件是肯定的一个或肯定的另一个，但有一个灰色主机在中间，判断必须使用。
方法refs背后的理论很简单：名称很重要。如果一个方法有一个名称，那么通过名称来引用它，而不是通过一个命令性的代码包来调用它，这通常是（但不总是！）更清晰易读。
关于性能或字符计数的争论主要是一些杂七杂八的问题，您应该忽略它们。我们的目标是编写非常清晰的代码。经常（但不总是！）方法引用在这个度量上是成功的，所以我们将它们作为一个选项，用于这些情况。
关于方法引用是澄清还是混淆意图的一个关键考虑是，从上下文中是否可以明显看出所表示的函数的形状。在某些情况下（例如。， map(Person::getLastName) ，从上下文中可以很清楚地看出，需要一个将一个事物Map到另一个事物的函数，在这样的情况下，方法引用会发光。在另一些情况下，使用方法ref需要读者想知道所描述的是什么样的函数；这是一个警告信号，说明lambda可能更具可读性，即使它更长。
最后，我们发现，大多数人一开始会避开方法引用，因为他们觉得比lambdas更新、更奇怪，所以一开始觉得它们“可读性较差”，但随着时间的推移，当他们习惯了语法后，通常会改变他们的行为，并在可能的时候倾向于方法引用。所以要意识到，你自己的主观初始“可读性较差”的React几乎肯定会带来某种程度的熟悉性偏见，你应该给自己一个机会，让自己在表达风格观点之前，对这两者都感到舒服。

由多个语句组成的长lambda表达式可能会降低代码的可读性。在这种情况下，在方法中提取这些语句并引用它可能是更好的选择。
另一个原因可能是可重用性。您可以构造一个方法并从代码的不同位置调用它，而不是复制和粘贴几个语句的lambda表达式。