我想说的是，peek提供了去中心化代码的能力，这些代码可以改变流对象，或修改全局状态(基于它们)，而不是将所有东西都塞进一个简单的或组合的函数中，传递给终端方法。

现在的问题可能是:在函数式java编程中，我们应该改变流对象还是从函数内部改变全局状态?

如果以上两个问题中的任何一个的答案是肯定的(或者:在某些情况下是)，那么peek()肯定不仅仅是用于调试的目的，就像forEach()不仅仅是用于调试的目的一样。

对于我来说，当在forEach()和peek()之间进行选择时，是选择以下内容:我想要突变流对象(或改变全局状态)的代码片段附加到可组合的，还是我想要它们直接附加到流?

我认为peek()将更好地与java9方法配对。例如，takeWhile()可能需要根据一个已经发生变化的对象决定何时停止迭代，因此与forEach()匹配将不会产生相同的效果。

注:我没有在任何地方提到map()，因为如果我们想要突变对象(或全局状态)，而不是生成新对象，它的工作方式与peek()完全相同。

尽管.peek的文档说明说“方法的存在主要是为了支持调试”，但我认为它具有普遍的相关性。首先，文档说“主要”，所以为其他用例留下了空间。多年来它没有被弃用，在我看来，关于它被移除的猜测是徒劳的。

我想说，在一个我们仍然需要处理副作用方法的世界里，它有一个有效的位置和效用。流中有许多使用副作用的有效操作。许多已经在其他答案中提到，我只是在这里添加一个对象集合上设置一个标志，或者将它们注册到注册表中，然后在流中进一步处理对象。更不用说在流处理期间创建日志消息了。

我支持在不同的流操作中有不同的动作的想法，因此我避免将所有内容都推入最终的. foreach。我更喜欢.peek而不是等效的带有lambda的.map，除了调用副作用方法之外，它的唯一目的是返回传入的in参数。.peek告诉我，一旦遇到这个操作，输入的内容也会输出，而且我不需要读取lambda来找出。从这个意义上说，它是简洁的，富有表现力的，并提高了代码的可读性。

话虽如此，我同意使用.peek时的所有注意事项，例如，注意使用.peek的流的终端操作的影响。

关键是:

不要以一种意想不到的方式使用API，即使它实现了您的直接目标。这种方法在将来可能会失效，而且对于未来的维护者来说也不清楚。

将其分解为多个操作并没有害处，因为它们是不同的操作。以一种不明确和意外的方式使用API是有害的，如果在未来的Java版本中修改了这种特定的行为，可能会产生后果。

在此操作中使用forEach将使维护者清楚地知道帐户的每个元素都有预期的副作用，并且您正在执行一些可能会改变它的操作。

它也更传统，因为peek是一个中间操作，在终端操作运行之前不会对整个集合进行操作，但forEach确实是一个终端操作。通过这种方式，您可以围绕代码的行为和流程进行强有力的论证，而不是询问peek在此上下文中的行为是否与forEach相同。

accounts.forEach(a -> a.login());
List<Account> loggedInAccounts = accounts.stream()
                                         .filter(Account::loggedIn)
                                         .collect(Collectors.toList());

为了消除警告，我使用了函数子tee，以Unix的tee命名:

public static <T> Function<T,T> tee(Consumer<T> after) {
    return arg -> {
        f.accept(arg);
        return arg;
    };
}

你可以替换:

  .peek(f)

with

  .map(tee(f))

我想说的是，peek提供了去中心化代码的能力，这些代码可以改变流对象，或修改全局状态(基于它们)，而不是将所有东西都塞进一个简单的或组合的函数中，传递给终端方法。

现在的问题可能是:在函数式java编程中，我们应该改变流对象还是从函数内部改变全局状态?

如果以上两个问题中的任何一个的答案是肯定的(或者:在某些情况下是)，那么peek()肯定不仅仅是用于调试的目的，就像forEach()不仅仅是用于调试的目的一样。

对于我来说，当在forEach()和peek()之间进行选择时，是选择以下内容:我想要突变流对象(或改变全局状态)的代码片段附加到可组合的，还是我想要它们直接附加到流?

我认为peek()将更好地与java9方法配对。例如，takeWhile()可能需要根据一个已经发生变化的对象决定何时停止迭代，因此与forEach()匹配将不会产生相同的效果。

注:我没有在任何地方提到map()，因为如果我们想要突变对象(或全局状态)，而不是生成新对象，它的工作方式与peek()完全相同。

似乎需要一个helper类:

public static class OneBranchOnly<T> {
    public Function<T, T> apply(Predicate<? super T> test,
                                Consumer<? super T> t) {
        return o -> {
            if (test.test(o)) t.accept(o);
            return o;
        };
    }
}

然后切换偷看与地图:

.map(new OneBranchOnly< Account >().apply(                   
                    account -> account.isTestAccount(),
                    account -> account.setName("Test Account"))
)

结果:只重命名测试帐户的帐户集合(没有维护引用)