C++11标准库不支持原生then()链式异步，需用std::promise/std::future手动桥接：每阶段创建新promise，前序future通过move传递并在唯一get()后set_value/exception，禁止拷贝future、漏处理异常或共享promise。
如何用 std::future 和 std::promise 构建可链式调用的异步任务
直接结论：C++11 起标准库不支持 then() 这类原生链式异步，但可以用 std::promise + std::future 手动桥接，关键在「把前一个 future 的结果作为下一个任务的输入」，且必须在线程安全前提下转移所有权。
常见错误是直接在 lambda 中捕获 std::future 并试图多次 get() —— std::future 是一次性消费对象，第二次 get() 会抛出 std::future_error: No state。
- 每个异步阶段必须创建新的
std::promise，并在前一阶段完成时调用其set_value()或set_exception() - 用
std::thread或std::async启动任务时，确保传入的 lambda 按值捕获前序std::future（避免悬空） - 若需传递非拷贝类型（如
std::unique_ptr），改用std::move转移，并确认接收端用右值引用参数接收
为什么不用 std::async 直接连写 then()？
因为 std::async 返回的 std::future 不提供注册回调的接口；它只支持阻塞等待（wait() / get()）或轮询（wait_for()）。强行“连写”如 std::async(...).then(...) 在标准 C++ 中根本不存在 —— 这是某些第三方库（如 Boost.Thread、facebook folly）或 C++20 std::jthread + 手动调度模拟出来的语义。
实际项目中若强依赖链式语法，建议明确引入 boost::asio::post + boost::asio::defer，或升级到 C++20 并配合 std::execution（仍在 TS 阶段，生产环境慎用）。
立即学习“C++免费学习笔记（深入）”；
- C++17 及之前：只能靠手动桥接
std::promise/std::future实现逻辑链，无语法糖 - 编译器对
std::async的 launch policy（std::launch::asyncvsstd::launch::deferred）行为不一致，可能导致看似异步实则同步执行 - 频繁创建
std::async任务易触发线程资源耗尽，应搭配线程池封装
一个可运行的三阶链式异步最小实现
以下代码实现「读文件 → 解析 JSON → 计算哈希」三级异步流水线，每级都返回 std::future，且不阻塞主线程：
auto read_file = [](const std::string& path) -> std::future<std::string> {
std::promise<std::string> p;
auto f = p.get_future();
std::thread([p = std::move(p), path]() mutable {
std::ifstream ifs(path);
std::string content((std::istreambuf_iterator<char>(ifs)),
std::istreambuf_iterator<char>());
p.set_value(std::move(content));
}).detach();
return f;
};
auto parse_json = [](std::future<std::string> f) -> std::future<nlohmann::json> {
std::promise<nlohmann::json> p;
auto out_f = p.get_future();
std::thread([p = std::move(p), f = std::move(f)]() mutable {
try {
auto s = f.get(); // 此处 get() 是唯一合法消费点
p.set_value(nlohmann::json::parse(s));
} catch (...) {
p.set_exception(std::current_exception());
}
}).detach();
return out_f;
};
auto calc_hash = [](std::future<nlohmann::json> f) -> std::future<size_t> {
std::promise<size_t> p;
auto out_f = p.get_future();
std::thread([p = std::move(p), f = std::move(f)]() mutable {
try {
auto j = f.get();
p.set_value(std::hash<std::string>{}(j.dump()));
} catch (...) {
p.set_exception(std::current_exception());
}
}).detach();
return out_f;
};
// 使用方式：
auto step1 = read_file("config.json");
auto step2 = parse_json(std::move(step1));
auto step3 = calc_hash(std::move(step2));
// 最终取结果（仅此处阻塞）
size_t h = step3.get();
注意 std::move() 传递 std::future 是强制要求：否则复制构造会失败（std::future 禁止拷贝），而编译器不会自动移动。
线程管理与异常传播最容易被忽略的细节
上面示例用 std::thread(...).detach() 简化演示，但真实场景中 detach 会导致异常无人捕获、资源泄漏风险极高。更稳妥的方式是统一用线程池管理，且每个任务内部必须包裹 try/catch 并调用 p.set_exception()，否则异常会终止线程而非传递给下游 future。
-
std::future::get()在上游未调用set_exception()时抛出的不是原始异常，而是std::future_error，调试时容易误判 - 多个任务共享同一份
std::promise实例会导致未定义行为 —— 每个std::future输出端必须对应唯一std::promise - 若某环节耗时极长（如网络请求），需额外加超时控制，不能依赖
std::future::wait_for()做取消 —— 标准 future 不支持取消，得自己设计 cancellation token
链式异步的本质不是语法糖，而是状态机 + 所有权精确移交；写错一处 move 或漏掉 exception 转发，整个链就静默崩塌。
