是的，for-each循环底层对Iterable类型调用Iterator，对数组则用索引遍历；两者字节码实现不同，语义与性能均有差异，且Iterator路径触发fail-fast机制。
for-each 循环底层真调用的是 Iterator 吗？
是的，Java 编译器会把 for-each 循环翻译成显式的 Iterator 调用（对 Iterable 类型），或数组的索引遍历（对数组类型）。它不是语法糖的“假实现”，而是有明确字节码映射的编译期转换。
这意味着：你写的 for (String s : list)，在字节码里实际等价于手动调用 list.iterator()、it.hasNext()、it.next() —— 所以任何影响 Iterator 行为的因素（比如并发修改、自定义 Iterator 实现）都会直接影响 for-each 的表现。
- 只适用于实现了
Iterable接口的类，或数组；其他类型（如普通对象）直接编译报错java.lang.Error: Unresolved compilation problem - 无法获取当前索引，也不能反向遍历；想改集合元素必须用显式
Iterator的remove() - 泛型擦除后，
Iterator返回的实际类型仍由编译器推导，不会出现运行时ClassCastException（除非你绕过泛型强转）
ConcurrentModificationException 为什么在 for-each 里特别容易触发？
因为 for-each 隐含的 Iterator 默认开启 fail-fast 检查。一旦集合结构被外部修改（比如在循环体里调用 list.remove(obj)），下一次 it.next() 就抛异常。
这不是 bug，是设计使然：它帮你快速暴露“一边遍历一边改”的逻辑错误。
立即学习“Java免费学习笔记（深入）”；
- 常见错误现象：
Exception in thread "main" java.util.ConcurrentModificationException，哪怕单线程也会触发 - 正确做法：用
Iterator自身的remove()方法（it.remove()），它会同步更新modCount - 替代方案：收集待删元素，循环结束后统一调用
list.removeAll(toRemove)；或改用CopyOnWriteArrayList（仅适合读多写少场景） - 注意：
ArrayList和HashMap的keySet()等视图都继承该行为，不是特例
数组的 for-each 和集合的 for-each 底层实现不同？
完全不同。数组走的是「索引访问」路径，不涉及 Iterator；而 Collection 子类走的是 Iterable.iterator() 路径。
这导致两个关键差异：性能和语义。
- 数组版 for-each 编译后是
aload_1+arraylength+iaload，无对象创建开销；Collection版必然 new 出一个Iterator实例（哪怕只是轻量对象） - 数组不能在循环中动态增删长度（本质不可变），所以不存在
ConcurrentModificationException；但你可以安全地修改数组元素值（arr[i] = ...） - 自定义类若同时实现
Iterable和支持数组风格访问，for-each 仍走Iterable分支 —— 编译器不看字段，只看类型声明
什么时候不该用 for-each？
当需要控制遍历节奏、依赖索引、或必须避免隐式对象分配时，就该退回到传统写法。
- 需要索引：比如处理相邻元素（
list.get(i)和list.get(i+1)），或构建带序号的日志，用普通for (int i = 0; i - 高性能敏感场景：如高频调用的工具方法中，避免每次循环都 new
Iterator（可复用或改用索引） - 遍历过程中要移除多个元素且逻辑复杂：显式
Iterator更可控，for-each容易漏掉it.remove()或误用collection.remove() - 调试困难时：IDE 断点打在
for-each行上，实际停在it.next()，堆栈不直观；遇到问题优先展开成显式迭代器再排查
最常被忽略的一点：for-each 的变量作用域是整个循环体，但它的初始化发生在每次迭代开始前——这意味着如果循环体里启动了异步任务并捕获该变量，所有任务可能共享最后一次迭代的值（闭包陷阱）。这时候显式用索引或提前复制更稳妥。
