答案是传统for循环最直接高效：需索引、改数组、条件跳过时首选；增强for简洁安全但无索引；Arrays.stream()灵活但有开销，三者依需求选择，不盲目追新。
Java 一维数组遍历本身开销极小，但不同写法在可读性、安全性、扩展性和JVM优化层面存在实际差异。真正影响“效率”的往往不是循环本身，而是访问模式、边界检查、缓存局部性以及是否触发额外对象创建。
优先用传统 for 循环（带索引）
当需要元素下标、修改原数组、或做条件跳过时，传统 for 循环最直接高效：
- JVM 对
i 的边界检查可能被 JIT 编译器优化掉（尤其数组长度不变时） - 避免 foreach 隐式创建迭代器对象（对基本类型数组无额外对象，但语义上更清晰）
- 支持提前 break、continue，也方便做相邻元素比较（如找峰值、连续子数组）
foreach 适合只读且无需索引的场景
代码简洁、不易越界，JVM 会将其编译为等效的传统 for 循环，性能几乎无差别：
- 适用于纯遍历打印、累加、查找匹配值等操作
- 不适用于修改数组元素（如
item = 10不会改变原数组） - 无法获取当前索引，若后续需索引还得额外维护变量
避免在循环中重复调用 length 属性
arr.length 是数组的 final 字段，访问极快，但习惯性写成 for (int i = 0; i 完全安全，无需提前缓存——现代 JVM 已对此做了内联和常量传播优化。
立即学习“Java免费学习笔记（深入）”；
只有在以下情况才建议缓存：
- 循环体内部有大量计算，且你明确观察到 profiler 显示
length访问成为瓶颈（极罕见） - 使用反射或代理包装的“类数组”结构（非原生数组）
慎用 Stream 遍历小规模数组
Stream API 语义清晰、函数式风格强，但有明显运行时开销：
- 创建 Stream 对象、装箱/拆箱（基本类型数组需转为 IntStream 等）、中间操作链构建都会带来额外 GC 压力
- 适合复杂数据转换（filter + map + reduce），而非简单遍历
- 对长度
不复杂但容易忽略：真正拖慢遍历的，往往是循环体内低效操作——比如每次迭代都 new 对象、调用远程方法、或做未缓存的字符串拼接。把注意力放在业务逻辑上，比纠结遍历语法更能提升实际效率。
