Java 8 Stream 的 map() 是中间操作，并不会立即执行；如果需要修改一个已有的 Set，应使用 forEachOrdered() 或 peek() 配合终端操作，而不是依赖 map() 的副作用。
许多开发者在使用 Java 8 流式编程时，常常陷入一个误区：试图通过 map() 这样的中间操作直接修改外部状态，比如向一个已有的 Set 中添加元素。看下面的代码，看起来逻辑清晰，对吧？
String[] arr = {"a", "abc", "b", "cd"};
Set dict = new HashSet<>();
Arrays.stream(arr)
.map(item -> {
System.out.println(item); // 虽然执行了，但流并未触发
dict.add(item); // 副作用发生了，但不可靠
return dict;
});
// ❌ dict 仍为空：map() 只构建了流水线，没有终端操作就不会执行！
实际上，这段代码根本不会执行——因为 map() 是中间操作，它只定义了转换规则，必须配合终端操作（比如 forEach、collect、count 等）才能驱动整个流水线真正运行。缺少终端操作，Stream 就像没有接电的开关，毫无作用。
那么正确的做法是什么呢？非常简单：使用语义明确、专门为“遍历并产生副作用”而设计的终端操作。
推荐方案：forEachOrdered()（线程安全且保持顺序）
Arrays.stream(arr)
.peek(System.out::println) // 非终端操作，仅用于调试或日志记录（惰性执行）
.forEachOrdered(dict::add); // 终端操作，按流顺序将每个元素添加到 dict
forEachOrdered() 有两个优点：首先，它是终端操作，能够真正触发流处理；其次，即使在并行流中，它也能保证按原始顺序执行。这里的 dict::add 是方法引用，简洁且安全。
⚠️ 注意事项：
- 不要在
map()、filter()等中间操作中编写副作用逻辑（例如修改外部集合、执行 IO 或更新计数器），这既违背函数式编程原则，也会导致不可预测的行为； peek()虽然常用于调试（如打印日志），但它仍然是中间操作，不能替代终端操作；单独使用stream.peek(...).peek(...)不会执行任何操作；- 如果不需要复用已有的 Set 实例，建议首选
collect(Collectors.toSet())——它更符合不可变和声明式风格，性能良好，并且在并行流中会自动处理线程安全问题：Set
dict = Arrays.stream(arr).collect(Collectors.toSet());
总结一下：Stream 的核心设计哲学是“构建 → 触发”——中间操作负责描述数据转换，终端操作负责驱动执行。修改已有集合属于典型的副作用场景，应严格使用 forEachOrdered()（有序）或 forEach()（无序），并且始终确保存在且仅有一个终端操作。坚持这一原则，才能编写出清晰、可靠、符合 Java 函数式编程范式的代码。
