不能直接支撑——std::future是单次结果容器，无任务分发与错误聚合能力；std::async需显式指定std::launch::async才能保证并发，须用vector缓存所有future并统一gather，避免循环内局部声明导致阻塞。
std::future 和 std::async 能否直接支撑 Scatter-Gather？
不能直接支撑——std::future 本身只是单次结果容器，不提供任务分发、批量等待或错误聚合能力；std::async 可启动异步任务，但默认使用 std::launch::deferred | std::launch::async 策略，若未显式指定，可能延迟执行甚至不并发，导致“假并发”。Scatter-Gather 的核心是：1）把输入切片（scatter），2）并发执行独立子任务，3）收集所有结果并合并（gather）。这需要手动组合 std::async、std::vector<:future></:future> 和同步逻辑。
如何正确启动并管理多个 std::future 子任务？
必须显式用 std::launch::async 强制并发，否则在 libstdc++ 或 MSVC 下可能退化为串行。同时，避免在循环中直接调用 get()——会阻塞等待当前 future，破坏并行性。应先 scatter 启动全部任务，再统一 gather。
- 用
std::vector<:future>></:future>缓存所有 future，确保对象生命周期覆盖到 gather 阶段 - 每个
std::async(std::launch::async, ...)必须捕获所需数据（推荐值捕获或std::move，避免悬垂引用） - 不要用
auto f = std::async(...)在循环内声明局部 future——析构会触发阻塞等待
std::vector<std::future<int>> futures;
for (int i = 0; i < 4; ++i) {
futures.push_back(std::async(std::launch::async, [i] {
return i * i; // 模拟子任务
}));
}
// 此时 4 个任务已并发运行gather 阶段：怎么安全取值并处理异常？
std::future::get() 是唯一取值方式，但它会：1）首次调用时阻塞直到就绪，2）抛出存储的异常（如子任务 throw），3）调用后 future 处于无效状态（valid() == false）。因此必须对每个 future 单独 try/catch，并在循环中检查 valid()（尤其当部分 future 可能被 move 后）。
- 不要依赖
wait_for+get组合来“避免阻塞”——get仍会阻塞，只是延后 - 若需超时控制，应在每个 future 上单独调用
wait_for，再决定是否get - 异常必须 catch，否则程序 terminate；建议用
std::exception_ptr收集后统一处理
std::vector<int> results;
for (auto& f : futures) {
try {
results.push_back(f.get()); // 阻塞在此，但所有任务已并发运行
} catch (const std::exception& e) {
// 记录 e.what()，或 rethrow，或存入 error vector
}
}Scatter-Gather 的实际瓶颈和替代建议
纯 std::future 实现缺乏任务取消、进度反馈、负载均衡和线程池复用能力。例如：某子任务卡死，整个 gather 就无限等待；无法动态调整并发度；频繁创建线程开销大。生产环境更常用 std::jthread + 通道（如 moodycamel::ConcurrentQueue）或成熟库（Intel TBB 的 parallel_for + combinable，或 HPX 的 dataflow）。
立即学习“C++免费学习笔记（深入）”；
- 若坚持用标准库，至少封装成模板函数，接受可调用对象、切片策略和合并器
- 注意：GCC libstdc++ 在较老版本中对
std::launch::async支持不稳定，建议 GCC ≥10 / Clang ≥12 - 真正关键的不是“怎么写 future”，而是“谁负责切片、谁定义合并逻辑、失败时是否重试”——这些业务逻辑必须显式编码，标准库不替你做
