直接用std::future和std::promise写任务链会卡死，因其get()阻塞且不支持自动触发延续；正确做法是解耦promise生命周期、用packaged_task替代裸promise、并在任务完成时用新promise设置下游结果。
为什么直接用 std::future 和 std::promise 写任务链会卡死
因为 std::future::get() 是阻塞的，而链式执行要求“前一个完成自动触发下一个”，不是等结果再手动调用。强行在主线程调 get() 会导致整个链串行阻塞，失去异步意义；若在线程里调 get() 又容易因未设置 std::launch::async 或忘记 std::move 导致挂起（比如 std::future 被拷贝后原对象失效，get() 永远等不到就绪）。
真正可行的链式异步，必须绕过 get()，改用 std::future::wait_for(std::chrono::seconds(0)) 轮询 + 回调注册，或更稳妥地：用 std::thread + 手动状态流转 + std::function 回调容器模拟“延续”（continuation）。
- 不要对同一个
std::promise多次调用set_value()，会抛std::future_error（错误码为promise_already_satisfied） -
std::future移动后原对象变空，再调valid()返回false，但很多人忽略这点，还在空 future 上调wait() - 跨线程传递
std::promise时，必须用std::move，否则编译失败（std::promise不可拷贝）
如何用 std::promise 实现单个任务的“可延续”封装
核心是把 std::promise 的生命周期和任务执行逻辑解耦：不把 promise 直接暴露给用户，而是包装成一个带 then() 方法的对象，内部持有 std::shared_ptr<:promise>></:promise>，并在任务完成时自动触发后续回调。
template<typename T>
struct Task {
std::shared_ptr<std::promise<T>> prom_;
std::function<void()> work_;
<pre class='brush:php;toolbar:false;'>Task(std::function<void()> f) : work_(std::move(f)) {
prom_ = std::make_shared<std::promise<T>>();
}
template<typename F>
auto then(F&& f) -> Task<std::invoke_result_t<F, T>> {
using R = std::invoke_result_t<F, T>;
auto next = Task<R>{[f = std::forward<F>(f), this](){
try {
T val = this->prom_->get_future().get(); // 这里仅用于当前 task 的 result
R res = f(std::move(val));
this->prom_->set_value(std::move(res)); // ❌ 错！这是覆盖原 promise
} catch(...) { /* handle */ }
}};
// 正确做法：在当前 work_ 执行完后，用新 promise 设置 next 的结果
work_ = [work = std::move(work_), next_prom = next.prom_, f = std::forward<F>(f)]() mutable {
try {
work();
T val = ...; // 假设 work 写入了 val 到某处
R res = f(std::move(val));
next_prom->set_value(std::move(res));
} catch(...) { next_prom->set_exception(std::current_exception()); }
};
return next;
}};
立即学习“C++免费学习笔记（深入）”；
注意上面示例中注释掉的错误写法——不能在 then() 里直接调 prom_->set_value()，那会污染上游 promise。真正要做的，是在当前任务执行完毕后，用下游 std::promise 设置其值。
为什么推荐用 std::packaged_task 替代裸 std::promise + std::thread
std::packaged_task 天然绑定一个 std::future，且可移动、可存储、可延迟执行，省去手动管理 std::promise 生命周期的麻烦。它让“任务提交”和“结果获取”自然分离，更适合链式场景。
- 构造
std::packaged_task<int></int>后，调task.get_future()立即拿到对应 future，无需额外 new promise - 把
taskmove 进线程或队列后，调task()即触发执行并自动满足 future，不用手动set_value - 多个
then()链路中，每个环节都应生成新的std::packaged_task，避免共享同一 future 导致状态混乱
典型误用：把同一个 std::packaged_task move 多次，第二次 move 后对象为空，调 () 会 crash —— 必须每次 then 都创建新 task。
实际链式调用中必须处理的三个异常点
链式异步最脆弱的地方不在正常流程，而在异常传播、取消和资源泄漏。C++ 标准库没提供 cancelation token，得靠约定：
- 每个任务函数签名建议为
std::function<void> on_done)></void>，显式传入完成回调，便于上层统一注入 cancel 检查 - 捕获异常后必须调
std::promise::set_exception(std::current_exception())，否则下游future.get()会抛std::future_error（而非原始异常） - 如果链中某步耗时长（如网络请求），又没有超时机制，整个链会被拖住 —— 必须在
then()内部启动独立 timer thread 或用std::future::wait_for做非阻塞等待
没有运行时调度器、没有协程支持的情况下，“链式异步”本质是回调嵌套 + 手动状态机。越想模拟 await 行为，越要小心栈深度、异常边界和 promise 生命周期交叉问题。
