返回Optional>而不仅仅返回一个空的Map的真正好处是什么？
在计算机编程中，像许多其他主题一样，“取决于”（tm）。我使用Optional作为null的替代品（简而言之）。它的一个优点是它强制调用者考虑可能没有返回值，并且这是一种有效的条件...考虑上面链接答案中的引用：
缺少值是一个比null更精确的表述
和
您代码的任何读者或API的任何使用者都会被强调可能没有任何值，并且在访问该值之前需要进行检查。
所以当我看到返回类型签名Optional<Map<String, String>>时，我认为它是一个函数的返回类型，其中空的Map可能是有效的返回值，但是完全缺少Map也是有效的返回值。例如getCachedFavoriteColors，findInvalidValuePairs等。在前一种情况下，可能没有任何用户，这将返回一个空的Map - 但可能没有缓存值，这将返回一个无效的Optional。在第二种情况下，可能没有任何无效的值对，这将再次返回一个空的Map，但也可能没有一个Invalidator。你明白我的意思了。
请注意，在上述某些情况下，你可能希望抛出异常而不是返回一个无效的Optional。这是作为API设计者的决定。
但是，Map可以是空的 - 任何使用Map的人都应该知道这一点，所以它同样被强调。我看不到额外的价值。事实上，你创建了另一种“这是空的”类型状态。现在你的引用可以是absent()、一个空的map，或者一个非空的map。这暗示了前两种状态之间的一些差别，并且在API的上下文中可能不太明显是什么差别。
但是（当然，这个想法需要慎重地应用于API设计）：Map中的元素缺失不同于Map的缺失。正是后者让Optional能够以简洁的方式表示。很难记住同时检查null和空map，很多时候人们会忘记，最终会抛出运行时错误。使用Optional，你可以将对null和空但已初始化的结构的检查压缩为一次检查。这就是我使用它们的方式，它确实使错误检查变得更容易。
如何检查Optional是否为空？除了optional.filter(x->!x.isEmpty())之外。似乎更冗长。
当然它们是不同的。但是你能想到一个在API中，缺少的map有用而空的map无用的例子吗？当然，缺乏证据并不意味着证据缺乏...但考虑到这增加了API的复杂性，我认为证明区别有用的责任在于支持Optional的阵营。这就是我所说的“我看不到额外的价值”。
无论你是否找到有用的例子都无关紧要。关键是说“只有当元素缺失和map缺失之间有区别时，它才有用”，这已经足以帮助你设计API。如果你从未遇到过这种情况，那么在你的场景中就没有Optional<Map>的用处。