Java 的 forEach 是 Iterable 接口默认方法，基于迭代器顺序执行，不支持 break/continue、索引访问或遍历时修改集合，异常直接抛出；适用只读副作用场景，否则应选 stream 操作或传统 for 循环。
Java 的 forEach 不能直接用于传统 for 循环那样的索引控制，它本质是 Consumer 接口的函数式遍历，适用于“只读+副作用”场景，不适合边遍历边修改集合或需要下标逻辑。
forEach 是 Collection 接口默认方法，不是语法糖
它定义在 Iterable 接口中（JDK 8+），所有实现类（如 ArrayList、HashSet、LinkedList）都可直接调用。底层调用的是 iterator() + hasNext()/next()，和增强 for 循环语义一致，但写法更函数式。
- 不能在 lambda 中使用
break或continue—— 没有循环体可跳转 - 无法获取当前元素索引，除非手动维护计数器变量（不推荐，易出错）
- 如果 lambda 抛异常，会原样向上抛出，不会被自动包装成
RuntimeException
遍历时修改集合会触发 ConcurrentModificationException
这是最常见的运行时错误。哪怕只是在 forEach 的 lambda 中调用 list.remove(x) 或 map.remove(key)，都会导致快速失败（fail-fast）机制抛出 ConcurrentModificationException。
- 正确做法：改用
Iterator.remove()，或先收集待删元素再批量操作 - 对
Map遍历，不要用map.forEach((k,v) -> map.remove(k))，应改用map.entrySet().removeIf(...) - 若需过滤后重建，优先用
stream().filter().collect(...)，语义更清晰且线程安全
替代方案：什么时候不该用 forEach
当你的逻辑涉及以下任一情况，forEach 就不是最佳选择：
- 需要中断遍历（如找到第一个匹配项就退出）→ 改用
stream().filter().findFirst() - 需要按索引处理（如只处理偶数位元素）→ 用传统 for 循环或
IntStream.range(0, list.size()) - 要同时修改多个集合或产生新集合 → 用
stream().map().collect() - 执行耗时 I/O 或可能阻塞的操作 → 注意它仍是同步执行，不会自动并行化；真要并行请显式调用
parallelStream()
list.stream()
.filter(s -> s.length() > 5)
.findFirst()
.ifPresent(System.out::println);
forEach 和增强 for 在性能上几乎没有差别
两者编译后都生成基于 Iterator 的字节码，JVM 层面优化程度接近。微基准测试（如 JMH）显示差异通常在 1–2% 以内，可忽略。
- 选择依据应是语义清晰度：
forEach更适合表达“对每个元素执行某操作”，增强 for 更适合需要局部变量或复杂控制流的场景 - 注意 IDE 可能将增强 for 自动提示为
forEach替代，但别盲目替换——尤其当循环体内有if/else嵌套或提前 return 时 -
forEach的 lambda 若捕获外部变量，会产生额外对象分配；高频调用场景建议权衡
真正容易被忽略的是：forEach 的 Consumer 参数是函数式接口，但它的执行仍是严格顺序、单线程的——即便在 parallelStream() 中，forEach 本身也不保证顺序，而 forEachOrdered 才保证。这点在日志打印、状态累积等场景极易引发隐蔽 bug。
