如何用增强for循环极其流畅地遍历只读性质的静态数组

先来一个最核心的结论：要实现“极其流畅”的只读遍历，关键不在循环怎么写，而在于数据源头是否真的安全。增强for循环（for-each）从设计之初就是为了简化这种场景，但它只是个忠实的“搬运工”，无法保证你搬的东西不被别人动手脚。

这么说吧，如果静态数组被声明为 public static final，里面的东西又是基本类型或者真正不可变的对象，那用增强for循环去读它，感觉就是两个字：丝滑。它剔除了索引、边界检查这些“噪音”，让你能完全聚焦在数据本身上，这才是它“流畅”的底层逻辑。

确保数组声明为 final 且无外部可变引用

想让遍历真正“只读”，设计意图必须从源头就封死。增强for循环可管不了你访问到的数组元素是不是个可变对象。所以，真正的安全措施得这么来：

• 首先，数据源本身要用 public static final 来声明。如果是基本类型数组（比如 int[]、double[]），到这里基本就安全了，数据本身无法被修改。
• 麻烦在于引用类型。如果数组里装的是像 StringBuilder 或者自定义的、带setter方法的对象，问题就来了。这时候要么返回一个元素的深度副本，要么就别直接暴露数组，而是通过一个公共方法返回一个不可变的集合视图（比如用 Collections.unmodifiableList 包装一下）。
• 一个黄金法则：尽量避免直接把内部的数组引用返回给外界。如果非得暴露，那就用私有数组加上一个公共的、只读的访问器，把所有修改的可能性掐灭在内部。

增强for写法干净到无需多余注释

一旦数据源本身是“铁板一块”，增强for的魅力就完全释放出来了。它的语法天然屏蔽了所有与“读”无关的细节。看看这个例子：

static final String[] ROLES = {"ADMIN", "USER", "GUEST"};
for (String role : ROLES) {
  System.out.println("Role: " + role);
}

看到了吗？没有 i，没有 length，自然也没有越界的焦虑。代码的语义（“遍历并读取每一个角色”）和行为完全一致，这就是它简洁到无需注释的底气——代码本身就是最好的说明。

遇到引用类型时，防修改比写循环更重要

这是最容易踩坑的地方。假设你有一个 Point[] 静态数组，即便用了增强for循环，你仍然可以在循环体里写出 point.x = 10 这样的修改语句。这时，“只读”的责任就完全落在了设计层面：

• 首选方案永远是使用不可变类。比如 Ja va 自带的 ja va.time.LocalDate、String，或者自己设计的用 final 修饰、字段私有且不提供设值方法的类。
• 如果某些历史原因必须使用可变对象，那么至少在初始化这个静态数组时，就填入那些在业务逻辑上不会被修改的实例。同时，必须在文档里明确指出：此数组为“逻辑只读”，请勿修改其元素。
• 在一些特殊场景下，可以作为一种防御性编程的提示，将数组先用 Arrays.asList() 包装，再获取其不可修改的视图。但要清醒地认识到，这只保证了返回的List视图不能add或remove，原数组本身通过其他途径还是可能被修改。

不推荐混用索引与增强for的“伪优化”

有时候你会看到一些别扭的写法：为了在增强for循环里“顺便”拿到索引，在循环体外维护一个计数器。又或者，写着写着发现需要索引，就硬生生把增强for又改回传统的for循环。

这些做法其实破坏了增强for循环的设计初衷。它生来就是为了让你心无旁骛地遍历元素。如果你发现自己需要索引，那首先要问：这个需求是不是已经超出了“只读遍历”的范畴？如果答案是肯定的，那就大大方方地使用传统的for循环，代码的意图会更清晰。强行在增强for的简洁躯壳里塞进索引逻辑，反而会让代码变得晦涩，失去了它原有的流畅美感。