也许我会引起一堆反对票和负面评论，但是……我站不起来了。
免责声明:我在下面写的并不是对最初问题的回答，而是我对这个话题的想法。它的唯一来源是我的想法和经验(使用Java和其他语言)。
首先让我们看看，为什么会有人喜欢使用可选?
对我来说，原因很简单:与其他语言不同，java没有内置的功能来定义变量(或类型)为空或非空。所有“object”变量都是可空的，而所有基元类型都不是。为了简单起见，在进一步的讨论中不要忽略原始类型，因此我将简单地声明所有变量都是可空的。
为什么需要将变量声明为可空/非可空?我的理由是:显式总是比隐式好。此外，显式修饰(例如注释或类型)可以帮助静态分析器(或编译器)捕获一些与空指针相关的问题。
Many people argue in the comments above, that functions do not need to have nullable arguments. Instead overloads should be used. But such statement is only good in a school-book. In real life there are different situations. Consider class, which represents settings of some system, or personal data of some user, or in fact any composite data-structure, which contains lots of fields - many of those with repeated types, and some of the fields are mandatory while others are optional. In such cases inheritance/constructor overloads do not really help.
随机的例子:假设，我们需要收集关于人的数据。但有些人不想提供所有的数据。当然这是POD，基本上是type with value-semantics，所以我希望它或多或少是不可变的(没有setter)
class PersonalData {
private final String name; // mandatory
private final int age; // mandatory
private final Address homeAddress; // optional
private final PhoneNumber phoneNumber; // optional. Dedicated class to handle constraints
private final BigDecimal income; // optional.
// ... further fields
// How many constructor- (or factory-) overloads do we need to handle all cases
// without nullable arguments? If I am not mistaken, 8. And what if we have more optional
// fields?
// ...
}
因此，IMO上面的讨论表明，即使大多数情况下我们可以在没有可空参数的情况下生存，但有时它实际上是不可行的。
现在我们来看看问题:如果一些参数是可空的，而另一些不是，我们怎么知道是哪个?
方法1:所有参数都是可空的(根据java标准，除了基本类型)。所以我们检查了所有的。
结果:代码中充斥着检查，而这些检查大多是不需要的，因为正如我们上面所讨论的，几乎所有时候我们都可以使用可空变量，只有在极少数情况下才需要“可空变量”。
方法2:使用文档和/或注释来描述，哪些参数/字段是可空的，哪些不是。
结果:它实际上不起作用。人们懒得写和读文档。此外，最近的趋势是，我们应该避免编写文档，而倾向于使代码本身自描述。此外，所有关于修改代码和忘记修改文档的理由仍然有效。
Approach 3: @Nullable @NonNull etc... I personally find them to be nice. But there are certain disadvantages : (e.g. they are only respected by external tools, not the compiler), the worst of which is that they are not standard, which means, that 1. I would need to add external dependency to my project to benefit from them, and 2. The way they are treated by different systems are not uniform. As far as I know, they were voted out of official Java standard (and I don't know if there are any plans to try again).
方法4:可选<>。缺点已经在其他评论中提到，其中最糟糕的是(IMO)性能惩罚。它还添加了一些样板文件，尽管我个人认为，使用Optional.empty()和Optional.of()并不是那么糟糕。优点是显而易见的:
它是Java标准的一部分。
对于代码的读者(或API的用户)来说，这些参数可能是空的。此外，它还强制API的用户和方法的开发人员通过显式地包装/展开值来确认这一事实(当使用@Nullable等注释时，情况并非如此)。
所以在我看来，任何方法论都不存在非黑即白的问题，包括这个方法。我个人总结了以下准则和约定(仍然不是严格的规则):
在我自己的代码中，所有变量都必须为非空(但可能是Optional<>)。
如果我有一个方法与一个或两个可选参数，我尝试重新设计它使用重载，继承等。
如果我不能在合理的时间内找到解决方案，我就会开始考虑性能是否关键(即是否有数百万个对象需要处理)。通常情况并非如此。
如果不是，我使用Optional作为参数类型和/或字段类型。
但仍有一些灰色地带，在那里这些惯例并不奏效:
我们需要高性能(例如，处理大量数据，因此总执行时间非常长，或者吞吐量非常关键的情况)。在这种情况下，由Optional引入的性能惩罚可能真的是不需要的。
我们在代码的边界上，这些代码是我们自己写的，例如:我们从DB、Rest Endpoint、解析文件等读取。
或者我们只是使用一些外部库，它们不遵循我们的约定，所以，我们应该再次小心……
顺便说一下，后两种情况也可以作为可选字段/参数的需求来源。例如，当数据的结构不是我们自己开发的，而是由一些外部接口，db-schema等强加的……
最后，我认为，人们应该思考正在解决的问题，并尝试找到合适的工具。如果Optional<>是合适的，那么我认为没有理由不使用它。
Edit: Approach 5: I used this one recently, when I could not use Optional. The idea is simply to use naming convention for method arguments and class variables. I used "maybe"-prefix, so that if e.g. "url" argument is nullable, then it becomes maybeUrl. The advantage is that it slightly improves understandability of the intent (and does not have disadvantages of other approaches, like external dependencies or performance penalty). But there are also drawbacks, like: there is no tooling to support this convention (your IDE will not show you any warning, if you access "maybe"-variable without first checking it). Another problem is that it only helps, when applied consistently by all people working on the project.
