std::async 不适合长期或资源密集型任务，因其默认策略不确定、线程行为未标准化，易导致阻塞、泄漏或串行执行；必须显式指定 std::launch::async 并及时处理 future，否则析构时会同步阻塞。
别用 async 做长期任务或资源密集型操作——它默认用的是线程池（或系统调度），但 C++ 标准没规定线程复用行为，实际表现因编译器而异，容易卡死、泄漏或响应迟钝。
为什么 std::async 有时根本不并发？
常见现象：连续调用多次 std::async，但 CPU 占用低、耗时串行增长，std::future::wait() 阻塞很久才返回。
- 默认启动策略是
std::launch::deferred或std::launch::async的组合，编译器可自由选择——GCC 12+ 默认倾向延迟执行，Clang 可能更激进启用线程，MSVC 行为又不同 - 没显式指定策略时，
std::async可能“假装”并发，实际等你调get()或wait()才真正执行（即惰性求值） - 如果函数里有静态局部变量或全局锁，即使启了新线程，也会被序列化阻塞
实操建议：std::async(std::launch::async, ...) 强制异步；但注意：这不保证线程立即创建，也不控制线程数上限。
std::async 返回的 std::future 必须及时取值或释放
常见错误：auto f = std::async([]{ return 42; }); 后没调 f.get() 或 f.wait()，程序退出时 future 析构会阻塞主线程，直到异步任务结束——哪怕任务已完，也可能卡住几毫秒到几秒。
立即学习“C++免费学习笔记（深入）”；
-
std::future析构时若未就绪，会同步等待完成（C++11 起强制语义） - 不能把
std::future存在容器里长期持有，除非你明确管理生命周期（比如用std::shared_future+ 弱引用计数） - 若只关心“触发不管结果”，可用
std::async(std::launch::async, []{ /*...*/ });并忽略返回值——但得接受无法捕获异常、无法确认是否真执行了
示例：std::async(std::launch::async, []{ throw std::runtime_error("boom"); }); —— 异常会被吞掉，且无任何提示。
替代方案比硬撑 std::async 更可靠
适用场景：需要可控线程数、任务排队、取消支持、异常传播或与现有线程池集成。
- 轻量级任务优先用
std::jthread（C++20），它自动 join/detach，支持中断：std::jthread t([](std::stop_token st){ while(!st.stop_requested()) { /*work*/ } }); - 需复用线程：直接封装
std::thread+ 队列，或用成熟库如boost::asio::thread_pool、tsl::robin_map配合自定义 executor（C++23std::execution还未普及） - 跨平台统一调度：避免依赖
std::async的实现细节，改用std::packaged_task+ 手动分发到线程，控制权完全在你手里
性能影响：std::async 每次调用都有额外开销（策略判断、状态机维护、future 包装），高频短任务下比裸 std::thread 慢 2–5 倍（实测 clang++15 -O2）。
最易被忽略的一点：C++ 标准对 std::async 的线程资源管理只字未提——它不负责回收、复用、限流。你以为起了个“轻量协程”，其实可能每调一次都 new 一个线程，而系统悄无声息地杀掉它，还留下僵尸句柄。
