std::async 默认不复用线程，高频调用易致线程爆炸；构建任务池需手动管理固定 worker 线程、线程安全队列及生命周期，推荐用 std::packaged_task 替代 std::async（deferred）以避免隐式执行与资源错配风险。
std::async 默认不复用线程，任务池必须自己管生命周期
直接裸调 std::async（不传 std::launch::deferred）会触发 std::launch::async 策略，每次调用都可能新建线程——这在高频任务场景下开销极大，且无法控制并发数。标准库不提供线程复用机制，所谓“基于 std::async 的任务池”，本质是用 std::async 封装任务提交接口，但底层必须自己维护线程队列和任务分发逻辑。
常见错误是以为写个 std::vector<:future>></:future> 收集返回值就叫任务池，结果压测时线程数爆炸、上下文切换飙升、甚至触发系统线程创建失败（std::system_error: Resource temporarily unavailable）。
- 必须显式创建固定数量的 worker 线程（如
std::vector<:thread></:thread>），每个线程循环消费任务队列 -
std::async在这里只用于包装单个任务为std::future，而非启动执行；真正执行由 worker 线程调用task()完成 - 任务队列需用线程安全容器（如
std::queue+std::mutex+std::condition_variable），避免忙等或虚假唤醒
如何让 std::async 与自定义线程池协同工作
关键不是让 std::async 去调度，而是把它当“未来值生成器”：把用户传入的可调用对象封装进 lambda，再用 std::async(std::launch::deferred, ...) 包一层，这样它不会立即执行，只生成一个可 later 调用的 std::future。worker 线程从队列取出这个 future 后，主动调用其 .wait() 或 .get() 触发执行。
示例核心片段：
立即学习“C++免费学习笔记（深入）”；
auto task = std::async(std::launch::deferred, [f = std::move(func)]() mutable {
f();
});
// 入队前可附加回调、超时控制等逻辑
task_queue.push(std::move(task));
- 必须用
std::launch::deferred，否则std::async可能立刻在线程池外执行，破坏调度一致性 - 捕获
func时用std::move避免拷贝，尤其当它是带状态的 lambda 或大对象时 - 不要对 deferred future 调用
.wait_for(...)，它不支持超时等待；如需超时，应在入队前加 wrapper 或用std::packaged_task替代
std::packaged_task 比 std::async 更适合任务池场景
虽然标题写的是 std::async，但实际工程中更推荐用 std::packaged_task。它不绑定执行策略，只负责把可调用对象转为可 move、可存储、可手动调用的对象，并自带 std::future 接口。相比 std::async，它没有隐式线程启动风险，语义更清晰，性能也略优（少一次封装跳转）。
典型替换方式：
// 原来用 async 包装
auto fut = std::async(std::launch::deferred, []{ return 42; });
// 改用 packaged_task
std::packaged_task<int()> pt([]{ return 42; });
auto fut = pt.get_future();
// 入队 pt，worker 线程 later 执行 pt()
-
std::packaged_task是可移动不可复制的，天然适配队列传输 - 它的
get_future()返回的 future 和std::async行为一致，上层代码无需修改 - 若需传递参数，用 lambda 捕获或
std::bind，不要试图把参数塞进 packaged_task 构造——它只接受无参签名
销毁顺序不当会导致 std::future::wait() 死锁
任务池析构时，如果 worker 线程还在运行、而任务队列已销毁，或者 future 被提前释放，worker 线程调用 future.wait() 会永远阻塞（因为 promise 已不存在）。这不是竞态，是资源生命周期错配。
- 必须先通知所有 worker 停止取任务（如设置
stop_flag = true+cv.notify_all()） - 然后
join()所有 worker 线程，确保它们完全退出后再销毁队列和 future 相关资源 - 避免在析构函数里直接调用
future.get()—— 如果任务还没执行完，会卡死整个析构流程 - 考虑用
std::shared_ptr管理 task 和 future 的生命周期，比裸指针或栈对象更容错
最易被忽略的一点：即使你用了完美的 RAII 封装，只要 worker 线程里存在未 catch 的异常，整个线程会 terminate，导致后续 join 失败、资源泄漏。务必在 worker 循环内包 try/catch。
