std::launch::async不保证立即异步执行，仅“偏好”异步，资源紧张时可能延迟至future.get()才启动；std::launch::deferred实为同步懒加载；默认策略行为不确定且不可移植；future析构会隐式等待async任务完成，易致阻塞或死锁。
std::launch::async 为什么不一定真异步
标准只要求 std::launch::async “偏好”异步执行，不保证立即创建线程。某些实现（如旧版 libstdc++）在资源紧张时仍可能延迟启动，直到 future.get() 被调用才真正开始运行任务。
这意味着你写 std::async(std::launch::async, f) 后立刻检查线程 ID，可能发现任务还没跑——它卡在“准备就绪但未调度”状态。这不是 bug，是标准允许的宽松语义。
- 若需强异步行为，必须配合
future.wait_for(std::chrono::milliseconds(0)) == std::future_status::timeout主动探测是否已启动 - 不要依赖“调用后立刻并发”做逻辑判断，比如在
std::async后立即读共享变量并假设已被修改 - 任务函数内尽早打日志或设原子标记，比依赖线程 ID 更可靠
std::launch::deferred 的同步陷阱
std::launch::deferred 看似省资源，实则把“异步”变成了“懒加载同步”。调用 future.get() 时，任务直接在当前线程执行，完全不新开线程——这会让原本想并行的逻辑意外串行化。
典型误用场景：在一个循环里连续启动多个 deferred 任务，最后统一 get()，结果所有计算都在主线程顺序执行，毫无并发收益。
立即学习“C++免费学习笔记（深入）”；
- 除非明确需要“按需触发+零线程开销”，否则慎用
std::launch::deferred - 若任务体含 I/O 或 sleep，
deferred会阻塞调用线程，失去响应性 - 调试时注意：
std::this_thread::get_id()在get()内和主线程一致，不是新线程 ID
不指定启动策略时到底发生了什么
默认调用 std::async(f) 等价于 std::async(std::launch::async | std::launch::deferred, f)，运行时可任选其一。这意味着同一段代码，在不同编译器、不同负载下行为可能完全不同。
libstdc++ 常倾向 deferred（尤其小任务），而 MSVC 更倾向 async。你无法预测，也不能测试覆盖所有环境。
- 生产代码中永远显式指定策略，禁用默认行为
- 若要兼顾资源与并发，应自行封装调度逻辑（例如用计数器限流 + 线程池），而非依赖
async的模糊语义 - 静态分析工具（如 clang-tidy）可配置规则拦截未指定 launch 策略的
std::async调用
future 析构时的隐式等待很危险
std::future 对象析构时，若任务尚未完成且使用了 std::launch::async，标准要求析构函数阻塞等待任务结束。这容易引发难以察觉的性能毛刺或死锁。
例如在局部作用域声明 auto f = std::async(...)，函数返回前 f 自动析构，主线程被迫卡住等后台任务收尾——哪怕你根本没调用 get()。
- 避免让
future生命周期短于任务预期耗时；必要时用std::shared_future延长生命周期 - 若任务允许丢弃，改用
std::thread+detach()，但需自行管理异常和资源 - 最稳妥做法：始终调用
wait()或get()，哪怕只是为确保析构时不阻塞
future 析构时的隐式同步等待——这两点在压测或跨平台部署时突然暴露，远比语法错误更难定位。 
