std::execution不是性能开关，而是将执行方式控制权交给开发者，但需满足数据、算法、硬件和代码的多重前提；否则std::execution::par可能更慢或崩溃，par_unseq对std::sort无效且危险。
std::execution 不是性能开关，它只是把“怎么跑”这个控制权交给你——但前提是你的数据、算法、硬件和代码都配得上它。
std::execution::par 为什么有时更慢甚至崩溃？
根本原因不是策略本身有问题，而是你没满足它的隐含前提：
-
std::execution::par要求算法内部可安全拆分，且每个子任务无共享可变状态；std::sort在 libstdc++ 中对小数组（v.size() < 10000）仍走单线程路径，强行套par反而引入调度开销 - 若容器元素类型有非平凡移动/复制（如含
std::string或自定义分配器），并行时内存分配器争用会拖慢整体速度 - 在单核或超线程受限环境（如 CI 容器、WSL 默认配置）下，
par可能触发虚假唤醒或线程饥饿，表现为随机 hang 或 SIGSEGV
实操建议：先用 std::execution::seq 跑通逻辑，再在真实多核机器上测 par，并用 std::thread::hardware_concurrency() 确认可用核心数。
std::execution::par_unseq 对 sort 有效吗？
基本无效，还危险。这不是实现缺陷，而是语义限制：
立即学习“C++免费学习笔记（深入）”；
-
std::sort是分治算法，依赖中间 pivot 和分区顺序；par_unseq允许向量化+乱序执行，破坏了排序所需的内存访问模式 - MSVC STL 对
par_unseq + sort做了静默降级（自动回退到par），而 libstdc++ 会直接报std::system_error（错误信息：std::bad_function_call或operation_not_supported） - 真正受益的算法是那些“每个元素独立计算”的：比如
std::transform、std::reduce、std::for_each，尤其当 lambda 体足够重（如调用sqrt、log或简单数值积分）
示例：以下代码在现代 x86-64 CPU 上通常比顺序版快 2–4 倍：
std::vector<double> data(1'000'000, 1.0);
std::transform(std::execution::par_unseq,
data.begin(), data.end(),
data.begin(),
[](double x) { return std::sin(x) * std::cos(x); });
哪些 STL 算法真正支持并行且稳定？
别信文档里“支持 ExecutionPolicy”的泛泛而谈。实际经三大主流实现（libstdc++、libc++、MSVC STL）长期验证的只有这几个：
-
std::transform：只要 lambda 是纯函数（无副作用、不捕获可变引用），就安全 -
std::for_each：仅限修改元素自身（如x *= 2），禁用全局计数器、日志、文件写入 -
std::reduce：二元操作必须满足结合律（+、std::min、std::max可以；-、/不行），初始值类型要与迭代器 value_type 可转换 -
std::inclusive_scan/std::exclusive_scan：仅当使用std::plus<>{}等标准仿函数时才保证正确性
像 std::find_if、std::nth_element、std::partial_sort 虽语法合法，但在不同编译器版本间行为不一致——有的返回第一个匹配项，有的返回任意匹配项，调试时极难复现。
lambda 捕获和线程安全最容易被忽略的细节
看似无害的捕获，在并行上下文中就是未定义行为的温床：
- 禁止按引用捕获局部变量：
[&i] { ++i; }—— 多个线程同时改栈上同一地址，UB - 禁止捕获 this 指针后调用非 const 成员函数：
[this] { mutate_state(); }—— 若该函数修改成员变量，无锁即竞争 - 允许值捕获 const 对象：
[val = some_const_int] { return val * 2; }—— 安全，因为只读 - 若需累积结果，别用共享变量：
int sum = 0; for_each(par, ..., [&](int x) { sum += x; });—— 改用std::reduce或让每个线程写入局部 vector 再合并
最隐蔽的坑：vector 的 operator[] 是线程安全的（只要不 resize），但 std::string 的内部 COW 逻辑在某些旧 ABI（如 GCC 4.9 编译的库）中仍未完全清除，多线程写不同 string 实例仍可能触发引用计数竞争。
真正卡住多数人的从来不是“怎么写”，而是“怎么证明它在线上多核机器上每次运行都对”。别跳过 seq 基线测试，别绕过线程 sanitizer（-fsanitize=thread），也别假设所有 par_unseq 场景都能自动向量化——SIMD 启动门槛、对齐要求、分支预测失败，都会让优化变成负优化。
