std::execution::par 并非自动加速魔法，仅在数据规模大、内存连续、操作无副作用时有效；它仅保证线程级并行，不向量化、不乱序、不自动同步，误用会导致未定义行为或性能下降。
直接说结论：std::execution::par 不是“开个开关就变快”的魔法，它只在满足数据规模、内存布局、操作无副作用这三重条件时才真正带来收益；用错反而导致结果错误或性能下降。
std::execution::par 的真实行为边界
它只保证「线程级并行」：标准库实现会把输入范围切分成若干块，分发给多个线程执行，但不承诺向量化（SIMD），也不改变单个线程内操作的顺序。这意味着：
- 同一块内的元素仍按迭代器顺序处理，不会乱序
- 不同线程之间完全并发，共享变量访问必须手动同步
- 若算法内部有隐式状态（如
std::string的写时复制残留、自定义分配器的线程不安全操作），std::execution::par会放大问题而非掩盖 - 它不自动加锁，也不检测数据竞争——编译器和运行时都不会报错，只会产生未定义行为
哪些算法调用 std::execution::par 才算真正有效
不是所有带 std::execution 参数的函数调用都实际并行。主流 STL 实现（libstdc++ 12+、libc++ 14+、MSVC STL）中，稳定支持并行且实测有效的只有这些：
-
std::sort、std::stable_sort（仅当v.size() > 10^5且比较/移动开销显著时） -
std::for_each、std::for_each_n（纯计算、无副作用的 lambda） -
std::transform、std::copy、std::fill（连续内存 + 简单操作） -
std::reduce、std::transform_reduce（二元操作必须满足结合律，如+、std::max）
像 std::unique、std::partition、std::nth_element 虽语法合法，但各实现支持程度不一，不能默认并行生效。
立即学习“C++免费学习笔记（深入）”；
常见崩溃/结果错误的代码模式
以下写法在 std::execution::par 下极易出问题，且错误难以复现：
-
int sum = 0; std::for_each(std::execution::par, v.begin(), v.end(), [&](int x) { sum += x; });—— 共享可变状态，无同步，结果随机 -
std::for_each(std::execution::par, v.begin(), v.end(), [](auto& x) { x.push_back(1); });—— 多线程修改同一std::vector内部缓冲区，数据竞争 std::for_each(std::execution::par, lst.begin(), lst.end(), [](auto& x) { std::cout —— <code>std::cout非线程安全，输出交错甚至崩溃-
std::sort(std::execution::par, list.begin(), list.end());——std::list迭代器非随机访问，多数实现退化为串行，还引入额外开销
怎么验证 std::execution::par 是否真的起作用
别信文档，实测才是唯一依据：
- 先用
std::execution::seq跑通逻辑，确保功能正确 - 用
std::chrono::high_resolution_clock测量耗时，对比至少三次，排除抖动干扰 - 检查 CPU 使用率：并行生效时，应观察到多核负载明显上升（如
htop中多个核心持续 >70%） - 小数据量（
v.size() ）或轻量操作（如 <code>[](int x) { return x + 1; }）几乎必然更慢——线程创建/同步开销压倒计算收益
真正容易被忽略的是：并行策略对内存访问模式极其敏感。哪怕数据规模够大，如果操作触发大量 cache miss 或跨 NUMA 节点访问，std::execution::par 可能比串行还慢，而且这种 slowdown 往往没有明显报错信号。
