std::async 是延迟启动的异步执行包装器，非线程池也非协程；默认策略 deferred 会推迟到 get()/wait() 时才执行，易因临时 future 析构导致隐式阻塞。
std::async 是什么，它真能“简单”启动异步任务？
它不是线程池封装，也不是协程替代品，而是一个延迟启动的异步执行包装器。调用 std::async 时，任务不一定立刻运行——取决于你传的 std::launch 策略。默认策略 std::launch::deferred 甚至会把执行推迟到你第一次调用 get() 或 wait() 时才发生，这和直觉里的“异步”相去甚远。
- 常见错误现象：
std::async返回的std::future对象被提前析构，导致程序阻塞在析构函数里（尤其在临时对象场景） - 使用场景：适合单次、无依赖、结果必取的轻量计算（比如预加载一个配置、算个校验和）
- 性能影响：若用
std::launch::async，每次调用都可能创建新线程；频繁调用 = 频繁线程开销，比手写std::thread+std::promise还重
怎么避免 std::async 的隐式阻塞？
核心是别让 std::future 成为临时对象，也别忽略它的生命周期管理。最典型的坑就是写成 std::async([]{ return 42; }).get(); —— 这里 std::future 是纯右值，get() 调用前它还没开始执行（deferred），调用后立即阻塞并等待完成，完全没并发可言。
- 正确做法：把返回值存为具名变量，显式控制何时
get()或wait() - 必须指定
std::launch::async才能确保后台执行，例如：auto fut = std::async(std::launch::async, []{ return heavy_work(); }); - 如果只是想“发出去就不管”，又不关心返回值，用
std::async(std::launch::async, []{ /* no return */ });是合法的，但注意 future 仍需析构（否则可能阻塞）
std::async 和 std::thread 哪个更适合你的场景？
如果你不需要返回值、不打算等结果、也不需要异常传播，std::thread 更直接、开销更低；std::async 的真正价值只在你需要一个带类型安全、自动异常捕获、且能自然组合的 std::future 时才体现出来。
- 参数差异：
std::async支持完美转发参数，和std::thread一样，但它的 lambda 捕获或参数若含非movable类型（比如std::array大对象），可能触发复制而非移动，要注意构造成本 - 兼容性影响：C++11 起支持，但某些老编译器（如 GCC 4.7）对
std::launch::deferred实现有 bug，建议明确指定策略 - 异常处理：
std::async会把异常保存在 future 中，get()时重新抛出；std::thread中未捕获异常直接终止程序——这点不能忽略
为什么 std::async 不该用于高频、短时任务？
因为它的调度不可控：底层实现可能复用线程，也可能新建，标准没规定。实测中，连续调用 100 次 std::async(std::launch::async, ...)，可能生成 100 个线程，也可能只用 4 个，全看 libstdc++/libc++ 的内部策略。这不是 bug，是标准允许的自由度。
立即学习“C++免费学习笔记（深入）”；
- 容易踩的坑：用它做事件循环里的回调分发，结果线程数爆炸或响应延迟抖动极大
- 替代方案：短任务优先考虑无锁队列 + 固定线程池（如自己封装或用
boost::asio::thread_pool） - 调试线索：观察
/proc/[pid]/status的Threads:行（Linux），或用top -H看实际线程数，别只信代码逻辑
std::async 的“简单”是有条件的：它简化的是结果获取和异常传递，而不是并发模型本身。一旦任务间有依赖、要限流、需取消或共享状态，它立刻变得比手写更难维护。
