增强 for 循环编译后等价于传统 for + 数组访问，对原生数组性能无差异；但遍历集合时需创建 Iterator 对象，有额外开销；传统 for 支持索引操作，适用跳过元素、相邻访问等场景。
增强 for 循环编译后就是传统 for + 数组访问
Java 的 for (Type x : array) 在字节码层面没有魔法，编译器会把它转成带索引的传统 for 循环，比如 array[i]。这意味着对原生数组（int[]、String[] 等）来说，两者最终执行的指令几乎一致，JIT 优化后性能差异可以忽略。
常见错误现象：有人用 JMH 测出“增强 for 慢 5%”，其实是因为没预热、样本少，或者混入了装箱操作（比如遍历 Integer[] 而非 int[]）。
- 增强 for 对
int[]、Object[]这类数组，底层就是array.length+array[i]，没额外对象创建 - 但若写成
for (String s : list)（list是ArrayList），它调用的是iterator()，涉及对象分配和方法调用开销 - 参数差异：增强 for 隐藏了索引变量，你拿不到当前下标；传统 for 可以随时用
i做边界判断或反向遍历
传统 for 在需要索引或跳过元素时不可替代
一旦逻辑里要访问相邻元素、做下标计算、或条件跳过（比如每两个取一个），增强 for 就得额外引入计数器变量，反而更啰嗦且易错。
使用场景举例：复制数组前半部分、合并两个等长数组、实现滑动窗口——这些都依赖明确的 i 和 j。
立即学习“Java免费学习笔记（深入）”；
- 想跳过第一个元素？
for (int i = 1; i 直接；增强 for 得加 <code>if (i == 0) continue，但你根本没有i - 遍历一半就停？
i 清晰；增强 for 得靠外部计数器 + <code>break，可读性下降 - 性能影响：传统 for 多一次
i++和比较，但现代 CPU 分支预测极强，这点开销在绝大多数业务代码里为零
增强 for 在 foreach 场景下更安全，但别误用在修改集合时
增强 for 写起来快，也天然规避了 i 写成 <code> 导致的 <code>ArrayIndexOutOfBoundsException。但它有个硬伤：遍历过程中不能修改正在遍历的集合（包括数组长度不变但内容变的情况）。
错误现象：for (String s : list) { list.remove(s); } 会抛 ConcurrentModificationException（ArrayList）或行为未定义（数组本身不能删，但若封装在 Arrays.asList() 返回的列表里就会崩）。
- 数组本身不可增删，所以“修改数组内容”没问题，但“以为在改集合”就容易踩坑
- 如果真要边遍历边删，用
Iterator.remove()或倒序传统 for（for (int i = list.size()-1; i >= 0; i--)） - 兼容性注意：增强 for 要求类型擦除后能匹配，比如
Object[]可以，但int[]和Integer[]混用时，前者不能直接赋给后者，编译就报错
JIT 优化会让两者差距进一步缩小，别过早纠结
HotSpot 的 C2 编译器在方法被频繁调用后，会对循环做向量化、循环展开甚至完全内联。这时候 array[i] 和增强 for 编译出的等效代码，生成的机器指令常常一模一样。
实测过百万级 double[] 求和：开启 -XX:+TieredStopAtLevel=1（禁用 C2）时，传统 for 快约 3%；默认配置下，差值小于测量误差。
- 真正影响性能的是内存局部性、是否触发 GC、有没有隐式装箱，而不是 for 写法本身
- 如果你在写高性能数学库或游戏引擎内层循环，优先选传统 for —— 不是因为它快，而是因为你必须控制每个下标
- 日常业务代码里，选增强 for 更少出错，可读性更高；换成传统 for 唯一正当理由是“我需要下标”
最常被忽略的一点：很多人拿 ArrayList 的增强 for 和数组的传统 for 比，这根本不是同一维度的事——前者走迭代器，后者走连续内存访问，差一个数量级都不奇怪。比之前，先确认你比的是同一种数据结构。
