多维数组遍历应按内存布局顺序（行优先）进行，即先固定外层索引i、内层遍历j，以提升缓存命中率；反向遍历会导致大量cache miss，性能下降3–10倍；同时需缓存维度值、避免循环内重复计算索引或边界。
多维数组遍历看似简单，但实际中容易因内存访问模式、索引顺序或语言特性掉进性能陷阱——最典型的就是缓存不友好导致的巨量缓存缺失（cache miss），让本该毫秒级的操作拖慢数倍甚至数十倍。
按内存布局顺序遍历（行优先 vs 列优先）
多数主流语言（如 C、C++、Go、Java 数组、Python 的 NumPy）底层以行优先（row-major）方式存储多维数组。这意味着同一行的元素在内存中是连续存放的，而同一列的元素则相隔较远。
- 对二维数组
arr[i][j]，应优先固定外层索引i，内层循环遍历j（即先 i 后 j）； - 若反向写成先 j 后 i（如遍历列再遍历行），每次访问
arr[0][j]、arr[1][j]…会跨行跳转，极大破坏空间局部性； - 实测常见场景下，列优先遍历可能比行优先慢 3–10 倍，尤其在大数组（如 4096×4096）上差异显著。
避免重复计算索引或边界
在循环体内反复调用 arr.length、arr[i].length 或进行复杂下标运算（如 i * cols + j），会带来隐式开销，尤其在 JIT 编译器未能充分优化时。
- 提前缓存维度值：
const rows = arr.length, cols = arr[0].length; - 对扁平化的一维数组模拟多维访问，把
arr[i * cols + j]移到循环外计算步长，或用位移/乘法预处理； - 避免在循环条件中写
i ，改用常量比较更稳定可靠。
警惕语言特性的“假多维”结构
JavaScript 的 [[1,2],[3,4]] 或 Python 原生 list of lists 并非真正连续的多维数组，而是指针数组套嵌——每次 arr[i][j] 都是一次指针解引用+内存跳转，无法享受 CPU 缓存预取优势。
- 需要高频遍历的场景，优先选用底层连续存储的结构：如 NumPy 的
ndarray、Rust 的ndarraycrate、或手动分配一维 TypedArray（如Float32Array）并自行映射索引； - 若必须用嵌套数组，考虑将数据预先展平，并用函数封装坐标转换逻辑，减少运行时分支和间接寻址；
- 不要依赖
for...of或map()遍历多维结构——它们额外创建迭代器对象，且无法控制访问顺序。
合理使用向量化与分块（Blocking / Tiling）
当数组远大于 L1/L2 缓存容量时，即使按行遍历，也可能因数据集太大导致频繁换页。此时可引入分块策略，让每个子块尽量适配缓存大小。
- 例如对 8192×8192 矩阵，按 64×64 块划分，先处理一个块内的所有行和列，再移动到下一个块；
- 块尺寸并非越大越好：太小增加循环开销，太大超出缓存；经验值常取 32–128（取决于目标平台 cache line 大小和数据类型）；
- 现代库（如 OpenBLAS、Intel MKL）内部大量采用此技术，手动实现时建议结合
__builtin_prefetch（C/C++）或编译器提示（如 GCC 的restrict）辅助优化。
