正确做法是先用std::async启动全部任务并存入std::vector，再统一调用get()等待；若顺序调用get()会导致串行阻塞，丧失并发性。
std::async 和 std::future 如何正确等待多个任务
直接用 std::async 启动多个任务后，不能靠循环调用 get() 无脑阻塞——这会串行等待，失去并发意义。关键是要先启动全部任务，再统一等待完成。
常见错误是写成这样：
auto f1 = std::async([]{ return heavy_work(1); });
auto f2 = std::async([]{ return heavy_work(2); });
f1.get(); // 等完这个才轮到 f2
f2.get(); // 实际仍是串行
正确做法是把 std::future 存进容器，全部 launch 完再遍历 get()：
- 用
std::vector<:future>></:future>收集所有 future（注意类型需显式指定） - 每个
std::async必须用std::launch::async显式指定异步执行，否则可能延迟到get()时才真正运行 - 若任务有异常，
get()会重新抛出；建议用valid()判断 future 是否还有效，避免重复调用
std::packaged_task + std::thread 怎么手动合并结果
当需要更细粒度控制线程生命周期（比如复用线程池），std::packaged_task 比 std::async 更合适。它把可调用对象和 promise 绑定，执行后自动设置 future 值。
容易踩的坑：
-
std::packaged_task不可拷贝，只能移动；传给std::thread时必须用std::move() - task 执行完，对应
std::future才就绪；但若线程提前退出、task 未被执行，future 会永远阻塞 - 合并结果时别直接在主线程里反复
wait()，应改用wait_for(std::chrono::seconds(0))轮询，或用条件变量协调
示例中常漏掉对 std::future::wait() 返回值的检查——它只返回 std::future_status，不是布尔值，误当 true/false 用会导致逻辑错乱。
std::jthread 和 std::stop_token 能否简化异步等待逻辑
C++20 的 std::jthread 自带可协作中断能力，但它本身不提供“等待多个任务合并”的抽象，只是让单个线程更容易安全终止。
如果你的任务需要响应取消信号，又想等全部完成再合并：
- 每个线程内用
std::stop_token检查是否被请求停止，及时退出计算 - 不要在
std::jthread构造时直接传 lambda 并期待它返回 future——jthread的 join 是同步阻塞，和 future 无关 - 仍需配合
std::promise/std::future或原子变量来传递结果；std::jthread只负责线程管理，不替代结果聚合机制
换句话说：std::jthread 解决的是“怎么安全停”，不是“怎么等齐结果”。混用时务必分清职责边界。
用 std::shared_future 避免重复取值的典型场景
当多个地方需要读取同一个异步任务的结果（比如主线程和日志线程都要访问），直接用 std::future 会因移动语义失效；这时必须转成 std::shared_future。
转换时机很关键：
- 只能在原始
std::future还没调用get()或wait()前调用share()，否则抛std::future_error（错误码为std::future_errc::no_state） -
std::shared_future::get()是线程安全的，但多次调用返回同一值；若原始任务抛异常，所有shared_future的get()都会重抛 - 适合做结果广播：一个任务产出，多个消费者等待，且都不该影响彼此
合并多任务时，如果某结果要被多次消费（如统计+存盘+上报），用 std::shared_future 比复制原始 future 更稳妥，也比用全局变量或互斥量更轻量。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
