std::async默认不并行，必须显式指定std::launch::async才能确保异步执行；返回std::future需注意类型推导与析构阻塞问题，且不宜用于高频细粒度任务。
std::async 默认不并行，得显式指定 launch::async
直接调用 std::async(func) 很可能串行执行，连线程都不起——这是新手最常踩的坑。因为默认策略是 std::launch::deferred | std::launch::async，运行时可自由选择延迟执行（即调用 get() 时才同步跑）或真正异步。想确保并行，必须显式写死：std::async(std::launch::async, func)。
常见错误现象：std::async([]{ sleep(1); return 42; }) 看似开了线程，但没加 std::launch::async，实际可能等你调 get() 才执行，总耗时还是 1 秒，不是并发。
- 使用场景：需要立刻启动、不接受延迟执行的计算任务（如预加载、IO+CPU 混合任务）
- 性能影响：省略
std::launch::async可能导致“假并发”，压根没利用多核 - 兼容性：C++11 起支持，但某些旧编译器（如 GCC 4.8 早期版）对
deferred实现有偏差，强制用async更稳妥
返回值类型必须和 lambda/函数签名严格匹配
std::async 返回 std::future<t></t>，而 T 是推导出来的——一旦 lambda 里有隐式转换或返回 void，推导就容易出错。比如 std::async([]{ return 3.14; }) 推导为 double，但若你误存成 float 类型的 std::future，编译失败。
常见错误现象：auto f = std::async([]{ return 0; }); int x = f.get(); 看似没问题，但如果 lambda 内部抛异常或返回 std::optional<int></int>，get() 会抛 std::future_error 或类型不匹配。
立即学习“C++免费学习笔记（深入）”；
- 使用场景：数值计算、字符串处理等明确返回类型的轻量任务
- 参数差异：带参数的 lambda 要注意捕获方式——
[=]捕获值，[&]捕获引用（但引用在线程间共享很危险） - 建议：用
auto接std::future，避免手动写模板参数；必要时用std::future<decltype></decltype>显式约束
std::future 析构会阻塞，别让它在作用域末尾意外等待
std::future 对象析构时，如果结果还没取走（即没调过 get() 或 wait()），且它关联的是 std::launch::async 启动的任务，则析构会**阻塞直到任务完成**。这很容易造成“以为异步，实则卡主线程”的问题。
常见错误现象：
void bad_example() {
auto f = std::async(std::launch::async, []{
std::this_thread::sleep_for(2s);
return 1;
});
// 忘了 f.get() —— 函数返回时 f 析构，主线程卡 2 秒
}
- 使用场景：短生命周期函数内启动后台任务，但忘记收尾
- 解决办法：显式调用
f.wait()（不取值只等结束），或f.get()（取值并等），或把std::future移动到长期存活对象中（如类成员） - 注意：
std::shared_future可拷贝，适合多处等待同一结果，但析构规则相同
别拿 std::async 当线程池用
std::async 每次都新建线程（或复用系统线程池，行为未规定），开销不小。频繁调用（比如循环里 1000 次 std::async）会导致线程创建/销毁压力大，甚至触发系统资源限制（Linux 下可能报 Resource temporarily unavailable）。
常见错误现象：循环计算数组每个元素，写成 for (int i : v) futures.push_back(std::async(...))，结果比单线程还慢，或者程序崩溃。
- 使用场景：粗粒度并行（如 2–10 个独立子任务），不是细粒度循环并行
- 替代方案：真要循环级并行，用
std::thread+ 手动分段，或第三方库（tbb、OpenMP），或 C++17 的std::for_each(std::execution::par, ...) - 性能影响：线程创建成本约几十微秒，远高于函数调用；反复创建还会加剧调度抖动
真正难的不是怎么开线程，而是判断哪些任务值得并行、数据要不要保护、结果怎么聚合——这些没法靠 std::async 自动解决。
