std::transform_reduce比手写循环快，因其由标准库统一调度数据划分、局部归约与结果合并，避免手动线程/锁管理；需满足结合律、交换律，输入支持随机访问，函数无副作用，且执行策略须显式指定。
std::transform_reduce 为什么比手写循环快？
它不是单纯“多线程加速”，而是把数据划分、局部归约、结果合并三步全交给标准库调度，避免手动管理线程/锁/临时容器。关键在于：并行策略由执行策略（std::execution::par_unseq）触发，且要求二元操作满足结合律和交换律——比如 std::plus 可以，std::minus 不行。
- 输入迭代器必须支持随机访问（
std::vector、std::array行，std::list不行） - 变换函数（unary op）不能有副作用（比如修改全局变量、打印日志），否则结果未定义
- 归约函数（binary op）必须是纯函数，且对任意 a,b,c 满足
f(f(a,b),c) == f(a,f(b,c))和f(a,b) == f(b,a)
std::transform_reduce 的四个重载怎么选？
最常用的是四参数版本（输入范围 + 变换 + 归约 + 初始值），但容易漏掉「初始值类型」和「归约结果类型」不一致的陷阱。比如对 std::vector<double></double> 做平方和，初始值用 0（int）会导致中间计算被截断为 int。
- 用
0.0而不是0作为初始值，避免隐式类型降级 - 若输入是整型但想得到 double 结果，显式传入
0.0并确保 binary op 返回 double（如std::plus<double>{}</double>） - 执行策略必须显式传入第一个参数位，例如：
std::transform_reduce(std::execution::par_unseq, ...)，漏掉就退化为串行
并行 transform_reduce 报 “invalid execution policy” 错误
常见于编译器没开 C++17 或没启用并行算法支持。GCC 需要链接 -ltbb（或 -lgomp），Clang 默认不支持并行策略，MSVC 在 /std:c++17 下可用但需开启 /EHsc 和运行时库匹配。
- 确认编译命令含
-std=c++17（GCC/Clang）或/std:c++17（MSVC） - GCC 用户加
-ltbb（推荐）或-fopenmp -lgomp；TBB 更轻量、无 OpenMP 运行时依赖 - MSVC 中若用静态链接 CRT（
/MT），确保 TBB 或 OpenMP 库也静态链接，否则运行时报错 - 运行时抛
std::system_error且 message 含invalid execution policy，基本可判定策略未被识别
性能没提升甚至变慢？检查这几个点
并行不是银弹。小数据量、简单运算、cache 不友好访问模式，都会让并行开销（线程创建、任务分发、同步）反超收益。
立即学习“C++免费学习笔记（深入）”；
- 数据量低于 10k 元素时，串行通常更快；建议实测临界点，而非硬编码阈值
- 变换函数里避免 new/delete、文件/网络 I/O、锁竞争——这些会严重拖慢并行线程
- 确保数据在内存中连续（
std::vectorOK，std::deque不推荐），否则 cache miss 率飙升 - 用
std::execution::par_unseq而非par，允许向量化（SIMD），但要求变换和归约函数无数据依赖、无分支预测失败风险
