多维数组遍历性能瓶颈在于缓存局部性，行优先语言需外层循环行索引、内层循环列索引以匹配内存布局；列优先语言则相反；非连续结构需单独评估。
多维数组遍历的性能瓶颈，常常不在算法复杂度，而在缓存是否“够得着”——关键看访问顺序是否匹配内存布局。
认清内存存储顺序是前提
多数语言（如 C/C++、Go、Rust）采用行优先（row-major）布局：二维数组 arr[i][j] 中，i 是行号、j 是列号，同一行的所有元素在内存中连续存放。例如 arr[0][0]、arr[0][1]、…、arr[0][M-1] 紧挨着，下一行才接着放。
- 列优先语言（如 Fortran、MATLAB）则相反，同一列连续存储
- 不确定时，可查语言文档或用指针差值验证：
&arr[0][1] - &arr[0][0] == 1说明行优先 - 结构体数组、vector of vector 等非连续布局不适用此规则，需单独评估
循环嵌套顺序必须对齐内存走向
对行优先数组，外层控制行索引、内层控制列索引，才能保证每次访存都落在刚加载进缓存的同一缓存行内。
- ✅ 推荐写法：
for (int i = 0; i - ❌ 高风险写法：
for (int j = 0; j —— 每次 <code>i变化都跳过整行，跨距远超缓存行大小（通常64字节），大量未命中 - 三维及以上同理：最内层循环应对应内存中最密集维度（对行优先，即最后一个下标）
避免隐性破坏局部性的操作
即使循环顺序正确，某些写法也会悄悄瓦解缓存收益：
- 在循环体内重复调用
arr.size()或sizeof(arr)等可能阻止编译器优化，建议提前存为常量 - 使用
std::vector<:vector>></:vector>代替原生二维数组时，每行内存不连续，空间局部性大幅下降；密集计算场景优先用一维展平 + 手动索引：data[i * M + j] - 引入分支预测失败的条件判断（如稀疏访问中的
if (valid[i][j])）会打断连续访存节奏，必要时考虑分块处理或预筛选
简单验证与量化观察方法
不用 profiler 也能快速感知差异：
- 用相同数据规模（如 4096×4096 int 数组）对比两种遍历耗时，差距常达 2–5 倍
- 观察 L1/L2 缓存未命中率（Linux 下可用
perf stat -e cache-misses,cache-references ./a.out） - 将数组大小设为缓存行整数倍（如 64 字节对齐）并开启编译器向量化提示（
#pragma omp simd），能进一步放大局部性收益
