std::async默认延迟执行，即std::launch::deferred策略，调用get()时才在当前线程同步执行；需显式指定std::launch::async才能真正异步。
std::async 默认是延迟执行，不是真正异步
很多人以为 std::async 一调用就立刻开线程跑任务，结果发现主线程卡住、get() 阻塞很久，甚至性能比同步还差——这是因为默认启动策略是 std::launch::deferred，也就是“等你调 get() 时才在当前线程执行”，根本没并发。
要真正异步，必须显式指定 std::launch::async：
auto fut = std::async(std::launch::async, []{ return 42; });
- 不写策略或只写
std::launch::deferred→ 同步延迟执行，fut.get()触发本线程计算 - 只写
std::launch::async→ 强制新线程执行（但可能失败，见下条） - 写
std::launch::async | std::launch::deferred→ 运行时决定，系统按负载选；这是更稳妥的默认做法
std::future::get() 只能调一次，且会阻塞等待
get() 不是“取值”，而是“取并消费”：第一次调用会阻塞直到结果就绪，返回值后内部状态置为无效；第二次再调就会抛 std::future_error（错误码 std::future_errc::no_state）。
常见误用：
auto fut = std::async(std::launch::async, []{ return 123; });
int a = fut.get(); // ✅ OK
int b = fut.get(); // ❌ 抛异常：no state
- 如果需要多次读结果，自己缓存返回值，别反复调
get() - 不确定是否已调过？可用
fut.wait_for(0s) == std::future_status::ready先探测，但不能代替get()获取值 - 想非阻塞取值又不想丢结果？用
std::shared_future，它支持多次get()
std::async 捕获异常会包装进 future，不传播到调用线程
任务函数里抛的异常不会崩掉主线程，而是被 std::async 捕获、封装进 std::future。只有调用 get() 时才会重新抛出——这点常被忽略，导致“任务崩溃了但主程序毫无感知”。
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
示例：
auto fut = std::async(std::launch::async, []{ throw std::runtime_error("boom"); });
// 此时主线程完全正常，fut 对象有效
try {
fut.get(); // ❗这里才真正抛出 runtime_error
} catch (const std::exception& e) {
std::cout
- 忘记 try/catch
get()→ 程序直接 terminate - 用
wait_for或wait_until只能知道“是否完成”，不能提前知道有没有异常 - 若任务可能失败，
get()必须包裹在异常处理中，不能假设它只返回值
std::async 的生命周期和线程资源容易被忽视
std::future 析构时，如果关联的任务还没完成（且是 async 启动），标准要求析构函数**阻塞等待完成**——这意味着临时 future 变量作用域结束时，主线程可能意外卡住。
典型陷阱：
{
auto fut = std::async(std::launch::async, heavy_work);
// heavy_work 还没完，fut 离开作用域 → 主线程在这里等它结束！
} // ❗隐式同步点
- 避免无名临时
future：std::async(...).get()是最差写法，既没并发又白开线程 - 需要异步但不关心结果？用
std::thread+detach()，或把future存到容器里统一管理生命周期 - 大量短任务？注意线程创建/销毁开销，
std::async不复用线程，不适合高频调度
真正用好 std::async 的关键，不是怎么写那行调用，而是想清楚：这个任务是否值得单独线程、结果要不要等、异常怎么兜底、对象生命周期谁来管。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
