std::execution 是一组执行策略标记类型，用于告知标准库算法允许的执行方式；能否真正并行取决于实现支持、编译器配置和运行时资源，如 libstdc++ 当前对 par 基本不实现，而 libc++ 和 MSVC 需特定条件才部分支持。
std::execution 是什么，它真能开并行？
它不是开关，也不是线程池管理器，而是一组标记类型（std::execution::seq、std::execution::par、std::execution::par_unseq），用来告诉标准库算法“你允许我怎么调度执行”。但能否真正并行，取决于实现是否支持、编译器是否启用对应特性、运行时是否有足够资源——比如 libstdc++ 目前（GCC 13）对 par 的实现基本是空操作，而 libc++（Clang）在启用 -D_LIBCPP_ENABLE_CXX20_ALGORITHMS 且链接 libc++experimental 后才部分支持。
怎么传给 std::sort、std::transform 这类算法？
直接把执行策略作为第一个参数传入，顺序不能错。注意：它只对 C++17 起新增的重载有效，老式调用（如 std::sort(begin, end)）完全无视它。
- 正确写法：
std::sort(std::execution::par, v.begin(), v.end()) - 错误写法：
std::sort(v.begin(), v.end(), std::execution::par)（参数位置错，编译失败） - 常见误用：
std::for_each(std::execution::par_unseq, ...)—— 若 lambda 有副作用（如修改共享变量），par_unseq可能引发未定义行为，不是“更快就行”
为什么加了 std::execution::par 却没变快，甚至更慢？
并行开销（任务切分、线程调度、同步）本身有成本。小数据量下，串行反而更稳更快；另外，算法内部是否真做并行，取决于底层实现和容器迭代器类型——比如 std::vector 支持随机访问，适合切分；而 std::list 的 std::sort 即使传 par，大多数实现也退回到串行。
- 典型陷阱：对 1000 个 int 排序加
par，实测可能比seq慢 2–3 倍 - 建议阈值：通常数据量 > 10⁴ 且计算密集（如自定义比较函数含浮点运算）才值得试
- 验证方式：别只看 wall time，用
perf stat -e task-clock,context-switches看是否真起了多线程
Windows / MSVC 下能用吗？
可以，但得满足三个硬条件：/std:c++17 或更高、/experimental:parallel-algorithms 开关、链接 vcpkg install parallel-algorithms 提供的库（官方 STL 目前仍不内置完整实现）。否则即使语法通过，运行时仍是串行——而且不会报错，只会静默降级。
立即学习“C++免费学习笔记（深入）”；
- MSVC 19.35+ 默认不启用，必须显式加编译选项，否则
std::execution::par被忽略 -
std::execution::unseq在 MSVC 中等价于seq，别信文档里“向量化”的描述 - 跨平台项目慎用：Linux（Clang+libc++）和 Windows（MSVC）行为差异大，很难写出一致表现的代码
真正难的不是写对那行 std::execution::par，而是判断当前环境是否真把它当回事，以及你的数据和操作是否值得为它付出调度代价。
