那么，正如标题所问的那样，Java Streams可以被认为是迭代器模式的实现吗？
我们是否可以认为对集合的.stream()调用创建了某种迭代器，该迭代器允许您解析该集合的元素，而无需实际公开集合的表示形式？(这就是迭代器模式所暗示的，如果我没记错的话(
编辑：为了避免混淆，请注意我对Java的迭代器接口不感兴趣，我只想知道Java Streams是否可以被视为迭代器设计模式的实现，为什么？
我们可以认为对集合的
.stream()调用会创建某种迭代器吗？
是的，我们能！但有趣的问题是，它是什么样的迭代器？迭代器设计模式最初发表在GoF书中。在第260页，它指出：
迭代器有许多实现变体和替代方案。
我们可能没有将流识别为迭代器，因为(在 Java 中(我们习惯于看到客户端显式调用next()和hasNext()的模式版本。流显然不是迭代器模式的那个版本，那么它们是什么？
谁控制迭代？一个基本问题是决定哪一方控制迭代，迭代器或使用迭代器的客户端。当客户端控制迭代时，迭代器称为外部迭代器，当迭代器控制迭代器时，迭代器称为内部迭代器。使用外部迭代器的客户端必须推进遍历，并从迭代器显式请求下一个元素。相反，客户端向内部迭代器提供要执行的操作，迭代器将该操作应用于聚合中的每个元素。
毫无疑问，Java Stream API在设计时考虑了Iterator模式，尤其是该模式的内部版本，因为Stuart Marks和Brian Goetz都慷慨地在SO上发布了他们的设计决策。斯图尔特提到了最初的原型是如何基于Iterable本身的。这对于并行处理来说是不够的，Brian 描述了 Stream API 的最终实现现在如何基于Spliterator。
因此，Stream仍然是一个迭代器，而是一个内部迭代器，而不是像Iterator和Enumeration这样的旧Java API。