在Java开发中，集合遍历是最基础也最高频的操作之一。虽然我们可以用传统的for循环配合下标，或者显式使用Iterator，但官方文档和主流代码规范都更推荐for-each语法。这背后不仅是代码简洁度的差异，更涉及安全性与底层机制。
一、for-each本质上是语法糖
很多初学者以为for-each是Java凭空造出的新循环结构，其实它只是编译器提供的语法糖。对于实现了Iterable接口的集合，for-each在编译期会被转换为Iterator的调用；对于数组，则转换为传统的下标循环。我们可以通过一段简单代码观察其等价写法。
下面的示例展示了同一个遍历逻辑的两种写法，左侧是for-each，右侧是编译后近似形态：
import java.util.ArrayList;
import java.util.List;
public class Demo {
public static void main(String[] args) {
List<String> list = new ArrayList<>();
list.add("a");
list.add("b");
// for-each写法
for (String s : list) {
System.out.println(s);
}
// 编译器近似转换后的写法
for (java.util.Iterator<String> it = list.iterator(); it.hasNext(); ) {
String s = it.next();
System.out.println(s);
}
}
}
从这段等价代码可以看出，for-each并没有消除Iterator，只是把hasNext、next的样板代码交给了编译器。这样做减少了手写出错的可能，也统一了数组与集合的遍历风格。
由于for-each对数组也会生成下标循环，因此它在性能上与手写循环几乎无异，在集合场景下还顺带获得了Iterator的fail-fast保护，属于零成本抽象。
二、避免下标越界与结构误用
当使用传统for循环遍历List时，开发者需要手动维护索引变量，并在条件中调用size方法。如果集合在循环中被其他逻辑意外修改，或者初始size计算有误，就可能抛出IndexOutOfBoundsException。而for-each完全不涉及下标，从语言层面封堵了这类低级错误。
更重要的是，Set、Queue等集合本身没有下标概念，用传统for循环根本无法遍历。如果强行把集合转为数组再遍历，既浪费内存又让代码变得啰嗦。for-each凭借统一的Iterable协议，让任意集合类型都能用同一行代码完成遍历。
import java.util.HashSet;
import java.util.Set;
public class SetDemo {
public static void main(String[] args) {
Set<Integer> set = new HashSet<>();
set.add(1);
set.add(2);
// 只能用for-each或显式Iterator
for (Integer num : set) {
System.out.println(num);
}
}
}
上面的代码如果用普通for循环，连编译都无法通过，因为Set没有提供get(int index)方法。for-each在此不仅是风格推荐，更是唯一合理的简洁方案。
另外在嵌套循环或复杂抽取方法中，手写下标极易出现i、j混淆，而for-each用独立的变量名隔离了作用域，可读性优势明显。
三、及时暴露并发修改问题
集合在遍历时被修改是常见隐患。显式Iterator在每次next调用前都会检查modCount，一旦发现集合结构变化就会抛出ConcurrentModificationException。for-each因为底层就是Iterator，所以同样具备该fail-fast能力。
反观某些开发者自己写的while循环配合get(i++)，若漏写校验逻辑，就可能一边遍历一边删除却毫无报错，最终产生漏删或数据错乱。下面演示一个错误写法与正确写法的对比：
import java.util.ArrayList;
import java.util.List;
public class RemoveDemo {
public static void main(String[] args) {
List<String> list = new ArrayList<>();
list.add("a");
list.add("b");
list.add("c");
// 错误：普通for循环倒序删看似可行，但正序删会漏元素
for (int i = 0; i < list.size(); i++) {
if ("b".equals(list.get(i))) {
list.remove(i);
}
}
// 正确：for-each配合Iterator.remove
// 下面用显式Iterator表达for-each中无法调用remove的限制
java.util.Iterator<String> it = list.iterator();
while (it.hasNext()) {
String s = it.next();
if ("c".equals(s)) {
it.remove();
}
}
}
}
需要注意，for-each循环体内不能直接调用集合的remove方法，否则依然会触发ConcurrentModificationException。若需在遍历时删除，应当改用显式Iterator并调用其remove。但即便如此，for-each所依赖的Iterator机制仍是安全保障的基础。
从工程角度看，fail-fast能让我们在测试阶段快速暴露错误，而不是把隐患留到生产环境。这也是为什么代码评审中常要求用for-each替代裸下标循环。
四、可读性与规范统一
团队开发中，代码可读性往往比微小的性能差异更重要。for-each用一行声明清楚表达意图：我要依次处理容器里的每个元素。它去掉了样板代码，让审稿人把注意力放在业务逻辑上。
主流静态检查工具如Checkstyle、SpotBugs也都内置规则，对能用for-each却写了传统for循环的情况给出警告。遵循推荐写法可以减少工具噪音，也降低新人理解成本。
| 遍历方式 | 适用类型 | 安全性 | 代码量 |
|---|---|---|---|
| 传统for下标 | 仅List、数组 | 易越界、易漏改 | 多 |
| 显式Iterator | 所有集合 | fail-fast | 较多 |
| for-each | 所有Iterable与数组 | fail-fast | 最少 |
综合来看，for-each在几乎不损失性能的前提下，提供了更好的安全性、通用性与可读性。除非需要在遍历中按索引定位，或调用Iterator的remove，否则都应优先使用for-each来完成集合遍历。