直接用 std::future 链式调用会编译失败，因其不可拷贝、只可移动，且标准库未提供.then()接口，导致复制构造被删除；常见错误包括多次调用.get()崩溃、值捕获编译失败、shared_future无法实现真正异步接力。
为什么直接用 std::future 链式调用会编译失败
因为 std::future 不可拷贝，只可移动，且标准库没提供 .then() 这类链式接口。你写 future.then(...).then(...) 会报错：「use of deleted function’ std::future<...>::future(const std::future<...>&)</...></...>」。这不是语法糖缺失的问题，而是设计上就拒绝隐式共享和重复等待。
常见错误现象：
- 试图对同一个
std::future多次调用.get()→ 程序崩溃（std::future_error: No state） - 把
future存在容器里或传给 lambda 捕获值 → 编译不通过（拷贝构造被删除） - 用
std::shared_future替代 → 能编译，但无法实现真正异步接力（所有后续操作仍阻塞在同一个线程等前一个get()）
如何手动构建可链式传递的异步任务流
核心思路是：不用 future.get() 主动取值，改用 std::thread 或 std::async 启动新任务，在其内部等待上游 future 并触发下游 promise。每个环节只持有唯一 std::promise 和移动来的 std::future。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 每个“链节”封装为函数对象，接收一个
std::future<t></t>，返回一个std::future<u></u> - 用
std::move传递future，避免误拷贝 - 下游
promise的set_value()必须在上游future.get()返回后调用（否则可能提前触发） - 异常必须显式捕获并调用
promise.set_exception()，否则会 terminate
示例（简化版）：
template<typename T, typename F>
auto then(std::future<T> f, F&& func) -> std::future<decltype(func(std::declval<T>()))> {
std::promise<decltype(func(std::declval<T>()))> p;
auto ret = p.get_future();
std::thread([f = std::move(f), p = std::move(p), func = std::forward<F>(func)]() mutable {
try {
p.set_value(func(f.get()));
} catch(...) {
p.set_exception(std::current_exception());
}
}).detach();
return ret;
}
std::promise 在链中何时构造、谁负责析构
每个链节的 std::promise 应在该节启动时构造，由该节的执行线程持有并调用 set_value() 或 set_exception()。不能跨线程传递 promise 对象本身（它不可拷贝也不可移动），只能传递其 std::future。
关键细节：
-
std::promise构造后，若未调用set_value()/set_exception()就析构 → 抛出std::future_error: Broken promise - 使用
std::thread+detach()时，必须确保promise生命周期覆盖整个线程执行期；更安全的做法是用std::async(launch::async, ...)，让系统管理线程与 promise 生命周期 - 如果链中某节需要取消（比如超时），标准
std::promise不支持 cancel，得自己加std::atomic_bool控制或换用第三方库（如boost::fibers::promise）
实际项目中比 future/promise 链更靠谱的替代方案
原生 C++11/14 的 future/promise 链太容易写出资源泄漏、线程失控或异常未传播的代码。除非你明确控制所有线程生命周期且无取消需求，否则不建议手写长链。
更可行的选择：
- 用
std::jthread（C++20）替代std::thread+detach()，自动 join，避免悬垂线程 - 用
std::execution::unseq或std::execution::par_unseq（C++17 并行算法）替代手动链，适合数据并行场景 - 引入
libunifex或cppcoro：它们提供真正的task<T>和operator|链式组合，底层用 awaitable + scheduler 抽象，异常/取消/调度都已封装 - 如果已在用 Boost，
boost::asio::post+boost::asio::co_spawn是目前最稳的生产级异步链方案
手写 future 链最容易被忽略的一点：你永远没法保证下游 promise 的 set_value() 调用发生在哪个线程——这直接影响回调执行上下文。而这一点，恰恰是 UI 更新、IO 完成通知等场景的生死线。
