std::promise和std::future不能直接链式调用，因其get()阻塞且wait_for/wait_until无回调机制；需手动桥接前序future就绪与后序promise设置，注意单次set、移动失效、线程安全及析构阻塞等问题。
为什么 std::promise 和 std::future 不能直接链式调用
因为 std::future 的 get() 是阻塞的，而 wait_for() 或 wait_until() 又不提供回调入口——标准库没内置“任务完成自动触发下个任务”的机制。想链式执行，必须自己桥接：把前一个 std::future 的就绪通知，转为对下一个 std::promise 的 set_value() 调用。
常见错误是在线程里裸调 future.get() 等待，结果卡死主线程或引发竞态；或者用 std::async 嵌套但没管理生命周期，导致 std::future 析构时阻塞等待（尤其在临时对象场景）。
- 每个
std::promise只能调用一次set_value()/set_exception()，重复调用会抛std::future_error（错误码std::future_errc::promise_already_satisfied） -
std::future移动后原对象变为无效状态，再调用valid()返回false，此时调用get()会抛异常 - 不要跨线程共享未加锁的
std::promise对象本身——只共享其std::future，或用std::shared_ptr<:promise>></:promise>安全传递
用 std::thread + std::future::wait_for 手动轮询实现简单链式
适合轻量、低频、调试友好场景。核心是让前序任务完成后，主动触发后续 std::promise，而不是靠阻塞等待。
auto p1 = std::make_shared<std::promise<int>>();
auto f1 = p1->get_future();
auto p2 = std::make_shared<std::promise<std::string>>();
auto f2 = p2->get_future();
// 启动第一任务
std::thread t1([&p1]{
std::this_thread::sleep_for(100ms);
p1->set_value(42);
});
// 轮询等待 f1 就绪，然后触发 f2
std::thread t2([&f1, &p2]{
while (f1.wait_for(10ms) == std::future_status::timeout) {}
if (f1.valid()) {
try {
auto val = f1.get(); // 此处不会阻塞
p2->set_value("done: " + std::to_string(val));
} catch (...) {
p2->set_exception(std::current_exception());
}
}
});
t1.join(); t2.join();
std::cout << f2.get() << "\n"; // 输出 "done: 42"
注意：wait_for(10ms) 不是 busy-wait，但轮询间隔太小会浪费 CPU；太大则延迟增加。生产环境慎用，仅用于理解模型。
立即学习“C++免费学习笔记（深入）”；
用 std::packaged_task + std::thread 实现可传递结果的链式
std::packaged_task 天然绑定一个 std::future，且可移动、可存储，比裸 std::promise 更适合作为任务单元封装。
- 每个
std::packaged_task执行后，其关联的std::future自动就绪，无需手动set_* - 可以把前一个 task 的
future传给后一个 task 的参数，由后者在执行时调用get()（仍需注意异常传播） - 推荐用
std::shared_ptr包裹 task 避免悬空，尤其在线程中捕获局部变量时
auto task1 = std::make_shared<std::packaged_task<int()>>(
[]{ std::this_thread::sleep_for(50ms); return 100; });
auto task2 = std::make_shared<std::packaged_task<std::string(std::future<int>)>>(
[](std::future<int> f) -> std::string {
try { return "got: " + std::to_string(f.get()); }
catch (...) { return "error"; }
});
auto f1 = task1->get_future();
auto f2 = task2->get_future();
std::thread t1([task1]{ (*task1)(); });
std::thread t2([task2, f1 = std::move(f1)]{ (*task2)(std::move(f1)); });
t1.join(); t2.join();
std::cout << f2.get() << "\n"; // 输出 "got: 100"
真正实用的链式：用 std::async + lambda 捕获 future，但必须规避析构阻塞
std::async 默认启动新线程，但它的 std::future 析构时若未取值，会阻塞等待完成——这是最常被忽略的坑。
- 务必在 lambda 内部调用
get()或wait()，或显式用std::future::share()转为std::shared_future后再捕获 - 避免写
auto f = std::async(...);后直接结束作用域；应确保f在使用完毕后再销毁 - 如果要组合多个异步步骤，优先用
std::shared_future，它允许多次get()且不阻塞析构
例如：
auto f1 = std::async(std::launch::async, []{ return 42; });
auto sf1 = f1.share(); // 转为 shared_future
auto f2 = std::async(std::launch::async, [sf1]{
try { return std::to_string(sf1.get()) + "_next"; }
catch (...) { return "fail"; }
});
这里 f1 在离开作用域时不会阻塞，因为已转交给了 sf1；f2 也安全持有对 sf1 的引用。
实际链得越长，手动管理 shared_future 和异常传播就越容易出错。真要工业级链式，该上 boost::asio 的 post + then，或 C++20 的 std::jthread + 协程，而不是硬啃 promise/future 底层模型。
