std::promise和std::future不能链式调用，因get()阻塞且仅能调用一次，set_value()多次抛异常；需手动接力、move传递future、动态管理promise生命周期。
为什么 std::promise 和 std::future 不能直接链式调用
因为 std::future 的 get() 是阻塞的，且只能调用一次；std::promise 又无法被多次设置（set_value() 多次会抛 std::future_error）。这意味着你不能像 JavaScript 的 then() 那样自然拼接异步步骤。
常见错误现象：在 lambda 中捕获 std::future 后调用 get()，导致线程卡死；或试图复用同一个 std::promise 触发多个后续任务，结果程序崩溃并报 std::future_errc::promise_already_satisfied。
可行做法是手动“接力”——前一个任务完成时，用新创建的 std::promise 将结果传给下一个任务：
std::promise<int> p1;
auto f1 = p1.get_future();
<p>std::thread([&p1]{
std::this_thread::sleep_for(100ms);
p1.set_value(42);
}).detach();</p>
<p>// 不能写 f1.then(...), 但可以：
auto f2 = std::async(std::launch::async, [f1 = std::move(f1)]() mutable {
int x = f1.get(); // 这里必须 move，否则 f1 被拷贝（不合法）
return x * 2;
});
</p></int>
如何安全地实现「任务链」而不出错
核心原则：每个异步节点只消费一个 std::future，只产出一个新的 std::promise（或用 std::async 隐式生成）。
- 永远对传入 lambda 的
std::future使用std::move，避免隐式拷贝（std::future不可拷贝） - 不要在线程外提前调用
get()，尤其别在主线程等所有链路结束——这等于退化成同步执行 - 如果需异常传播，用
promise.set_exception(std::current_exception())，而非忽略catch块 - 考虑用
std::shared_future替代std::future，当需要多处读取同一结果时（比如分支任务）
实际项目中更推荐的替代方案
原生 std::promise/std::future 写链式逻辑太容易出错，尤其涉及错误处理、取消、超时等场景。生产环境建议：
- 用
std::jthread（C++20）替代裸std::thread，自动 join + 支持中断请求 - 用
boost::asio::post+boost::asio::awaitable（C++20 兼容）实现真正的协程链式写法，语法接近co_await task1() >> task2 - 若必须用标准库，封装一个轻量
Task类型，内部持有std::shared_ptr<:promise>>和状态标记，屏蔽重复 set / 移动语义细节
例如简单封装后可写出：Task —— 但底层仍是靠 promise/future 接力，只是把坑藏起来了。
最容易被忽略的生命周期陷阱
std::promise 对象本身必须活到 set_value() 或 set_exception() 被调用之后；而它的 std::future 持有者（比如 lambda 捕获的副本）必须活到 get() 完成。两者不同步，极易悬空。
典型翻车点：
- 在栈上创建
std::promise，然后把它 move 进线程 lambda —— 线程还没执行，promise 已析构 - 用
std::async返回的std::future，却没保存其返回值，导致 future 析构时阻塞等待（std::async默认 launch policy 是 deferred 或 async，但析构时行为不同） - 多个线程同时尝试
set_value()同一个 promise（即使加锁，也违反 promise 单次设置语义）
稳妥做法：所有 std::promise 动态分配（std::make_shared<:promise>>()），让生命周期由 shared_ptr 管理；std::future 统一 move 到 lambda，并确保 lambda 执行完毕前 promise 不销毁。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
