判断内层循环是否依赖外层变量是最直接依据；若未使用外层索引或值，通常可提取为独立循环；需借助GCC等编译器诊断标志（如-fopt-info-vec-optimized）验证优化效果与限制。
看内层循环是否依赖外层变量
这是最直接的判断依据。如果内层循环体里没用到外层循环的索引或值，那它大概率能提出来单独跑。
常见错误现象：for (int i = 0; i —— <code>j 和 i 完全无关，process(j) 被重复执行了 n 次。
- 检查所有内层循环中出现的变量：是否都来自内层声明，或来自外层但值不变（比如只读的
const参数） - 若存在对
arr[i][j]、vec[i].size()这类带i的访问，说明有真实依赖，不能简单剥离 - 注意隐式依赖：比如
std::vector的push_back可能触发重分配，影响后续迭代器有效性，表面无依赖实则有副作用
查是否有重复计算被塞进内层
很多“看似嵌套”其实只是把常量计算错放进了内层，导致性能浪费而非逻辑耦合。
典型例子：for (int i = 0; i 中，<code>data[i].size() 在内层每次都被调用，但它在 i 固定时是定值。
立即学习“C++免费学习笔记（深入）”；
- 把
data[i].size()提到内层循环外，缓存为局部变量const size_t row_len = data[i].size(); - 同理，
max_value、sqrt(2.0)、config.threshold等只要不随j改变，就该提前算好 - 用
clang++ -O2 -Rpass=loop-vectorize或gcc -fopt-info-vec可看到编译器是否提示“loop not vectorized: loop contains function call”，往往就是这类问题
观察内存访问模式是否连续
嵌套顺序直接影响缓存效率。如果当前写法导致 data[i][j] 是跨行跳着读，而改成 data[j][i] 能变成线性扫描，那不是“能否简化”，而是“必须重排”。
错误模式示例：for (int j = 0; j —— 对列主序存储（如 Fortran、<code>std::vector<:vector>></:vector> 的常见用法）是灾难性的。
- C++ 默认是行主序，优先保证
i外层、j内层时data[i][j]地址递增 - 若数据结构是列向量数组（如 Eigen 的
ColMajor），则相反：外层应为j - 用
perf stat -e cache-misses,cache-references ./a.out对比两种写法，miss ratio > 15% 就值得怀疑访问局部性
用编译器反馈验证是否真有优化空间
别靠猜。现代编译器会明确告诉你哪些循环被合并、展开或向量化了，哪些被判定为“无法优化”。
例如 GCC 提供的诊断标志：g++ -O3 -fopt-info-vec-optimized -fopt-info-loop-optimized，运行后会输出类似：
loop at test.cpp:42: vectorized: yes loop at test.cpp:45: not vectorized: control flow in loop body
- 如果某嵌套循环没出现在
-fopt-info-vec-optimized输出里，先检查是否含分支、函数调用或指针别名 -
-fsanitize=undefined有时能暴露因过度优化导致的越界——比如你把本该用i索引的逻辑错挪到外层，运行时才崩 - 真正“可简化”的嵌套，编译器通常会做
loop fusion（循环融合）或loop interchange（循环交换），这些在-fopt-info-loop里都有记录
复杂点在于：有些嵌套看着能拆，但一拆就破坏了数据依赖或并发安全；有些看似不可简，加个 restrict 或 [[likely]] 编译器就自动做了。动手前先看编译器怎么说，比凭经验改更可靠。
