直接用 std::future 链式调用会编译失败，因其不可拷贝、只可移动，且标准库未提供.then()接口；需手动用std::promise串接任务并严格管理生命周期与异常传播。
为什么直接用 std::future 链式调用会编译失败
因为 std::future 不可拷贝，只可移动，且标准库没提供 .then() 这类链式接口。你写 future.then(...).then(...) 会直接报错：「use of deleted function’ std::future<...>::future(const std::future<...>&)」。C++11/14 的 std::future 是“一锤子买卖”——只能取一次结果，也不能自动触发后续任务。
常见误操作：
- 试图把
std::future存进容器（如std::vector<:future>></:future>）而不 move - 在 lambda 捕获中按值捕获
future（触发拷贝） - 以为
promise.set_value()后 future 会自动调度下一个任务（不会，纯同步通知）
如何手动构建可链式传递的异步任务节点
核心是用 std::promise 手动控制下游 future 的就绪时机，并把“执行完当前任务 → 触发下一个 promise”这个逻辑显式串起来。每个节点封装一个 std::function 和一个 std::promise，上一个节点完成时，调用下一个的 set_value() 或 set_exception()。
实操要点：
立即学习“C++免费学习笔记（深入）”；
- 每个任务节点返回
std::future<t></t>，但内部持有std::promise<t></t>的独占所有权（用std::unique_ptr或 move-only 包装） - 前序任务的回调里，必须用
std::move传递 future 结果给后续任务（避免拷贝） - 异常必须显式捕获并调用
next_promise.set_exception(std::current_exception())，否则异常会丢失 - 推荐用
std::thread或线程池执行任务体，别依赖std::async的默认 launch policy（可能延迟启动）
简例示意节点连接逻辑：
auto task1 = [](int x) -> int { return x * 2; };
auto task2 = [](int x) -> std::string { return std::to_string(x); };
<p>// 伪代码：手动连接
promise1.set_value(42);
future1.then([task2, &promise2](int v) {
try {
promise2.set_value(task2(v)); // 成功路径
} catch (...) {
promise2.set_exception(std::current_exception()); // 异常路径
}
});</p>
std::packaged_task 比裸 promise/future 更适合链式场景吗
更适合。因为 std::packaged_task 天然绑定一个可调用对象和其对应的 std::future，且本身可移动、可存储、可延迟执行——省去手动 new promise + 绑定回调的样板代码。
关键优势：
-
packaged_task调用后自动满足其 ownfuture，无需手动set_value - 可直接塞进队列、lambda 捕获、或传给线程池（它满足
MoveConstructible） - 异常自动被捕获并设置到 future 中（不用手写
try/catch/set_exception） - 配合
std::function<void></void>封装，能自然形成执行链：「上一个 task 的 future.wait() → 触发下一个 task()」
注意点：
-
packaged_task不能拷贝，捕获时务必用移动语义（[task = std::move(my_task)]() mutable { task(); }） - 若需类型擦除（比如混合不同返回类型的 task），得用
std::any或自定义 variant 包装，packaged_task本身是模板，类型固定
实际项目中容易被忽略的生命周期陷阱
最典型的是 promise 对象早于 future 被析构。一旦 promise 析构而 future 还没 get，程序直接 terminate（C++ 标准规定未满足的 promise 析构 = 调用 std::terminate）。
必须守住的边界：
- promise 的生存期必须严格长于其对应 future 的所有使用点（包括所有可能的 get/wait/valid 调用）
- 若用 shared_ptr 管理 promise，future 侧无法感知，仍需确保 shared_ptr 不提前释放
- 在线程池中提交任务时，别把局部 promise 变量 move 进 lambda —— lambda 执行时该变量早已销毁
- 链式任务中，下游 promise 的构造必须发生在上游任务启动之后（不能全在主线程预分配好再逐个 launch）
一句话收尾：链式异步不是靠语法糖堆出来的，是靠 promise 生命周期、move 语义、异常传播三者严丝合缝卡准才跑得稳。漏掉任意一环，崩得悄无声息。
