传统for循环性能最优，适合需索引或高频遍历；增强for简洁安全但无法获取索引；stream功能强但开销大，仅适用于过滤、映射等函数式操作。
Java 数组遍历本身不复杂，但方式选错，小项目看不出问题，大数组或高频调用时，性能差异会立刻显现——关键不在“能不能跑”，而在“要不要多花几毫秒、多占点内存、多触发几次 GC”。
传统 for 循环：性能基准线，适合需要索引的场景
这是最贴近底层、JVM 优化最充分的方式。它直接通过下标访问，无额外对象创建，无装箱拆箱，实测百万级 int[] 遍历耗时稳定在纳秒级区间。
- 显式缓存 arr.length：写成
for (int i = 0, len = arr.length; i ，避免每次循环重复读取字段（虽现代 JVM 多数能内联，但显式更稳妥） - 支持反向遍历、步长跳变（如
i += 2）、条件截断（如i ） - 唯一能自然获取当前索引的方式，适用于查找位置、构建新数组、原地修改等操作
增强 for 循环（for-each）：简洁安全，适合只读遍历
它是语法糖，对数组而言，编译后仍转为基于索引的传统 for，性能几乎与手动写法持平，且杜绝 ArrayIndexOutOfBoundsException。
- 语义清晰：“我只关心每个值”，代码干扰少，可读性高
- 不能获取索引——若真需要，可额外声明计数器变量，但已失去简洁优势
- 不能通过循环变量修改原数组元素（
num = 100只改副本），如需修改，请用传统 for
Stream API：功能强大，但别为遍历而用
Arrays.stream(arr).forEach(...) 写起来很酷，但背后有真实开销：创建 Stream 对象、包装 IntStream、触发终端操作链路，还有基本类型装箱/拆箱成本。
- 实测百万级 int[] 遍历，比传统 for 慢 3–5 倍，GC 压力略高
- 仅建议用于真正需要函数式能力的场景：比如过滤（
filter）、映射（map）、聚合（sum、max）或并行处理（parallelStream） - 纯打印、累加、校验类操作，用 Stream 属于“杀鸡用牛刀”
大数组或高频场景下的额外提醒
当数组长度达十万级以上，或在热点路径（如网络请求处理循环、实时计算模块）中频繁遍历时，还需注意：
-
数据局部性：有序数组遍历通常比无序快得多——不是因为算法，而是 CPU 分支预测更高效；若逻辑含条件判断（如
if (x > threshold)），排序后可能提升数倍吞吐 - 避免在循环内做耗时操作：比如远程调用、文件读写、复杂对象构造，这些远比遍历本身慢几个数量级
-
慎用并发遍历：对纯数组，
ForkJoinPool.commonPool()或手动分段并行，收益常被线程调度和同步开销抵消；除非单次处理逻辑极重，且数组足够大（千万级+）
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
