C++实现异步任务的任务链式调用 _ std::future与promise模型【源码】

在C++中构建异步任务链，很多开发者第一个想到的就是std::future和std::promise这对组合。然而，一个常见的误区是试图模仿Ja vaScript Promise的then()风格进行链式调用。现实是，C++标准库（包括C++11/14/17）并未提供这样的语法糖。直接写future.then(...)只会换来编译器的无情报错：error: 'then' is not a member of 'std::future'。

那么，所谓的“链式”在C++里究竟意味着什么？其本质是手动将上一个std::future的结果，作为下一个异步任务的输入，并通过启动新线程或设置回调来触发后续流程。实现路径其实很明确：使用std::thread或std::async启动新任务，在该任务的函数体内，通过get()获取前序std::future的结果，再驱动后续逻辑。这里有个关键点：get()是阻塞调用，千万别在主线程里不加思索地使用它，否则整个异步链就会退化成同步串行执行，失去了并发的意义。

std::promise 和 std::future 不能直接链式调用，必须手动传递

手动管理std::promise和std::future时，有几个细节必须牢记于心，否则极易踩坑：

• 每个std::promise只能调用一次set_value()。重复设置会抛出std::future_error异常，其错误码为std::future_errc::promise_already_satisfied。
• 异常传播需要显式处理。如果前序任务异常退出，必须在捕获异常后，显式调用promise.set_exception(std::current_exception())。否则，下游调用future.get()时会直接触发std::terminate，导致程序终止。
• std::future对象是不可复制的，只能移动。移动之后，原对象进入无效状态，此时再调用valid()会返回false，调用get()则会抛出std::future_error。

用 std::packaged_task 包装可移动任务，解耦执行与获取

对于链式场景，std::packaged_task通常是比直接操作std::promise更优雅的选择。它本质上是一个可调用对象的包装器，内部绑定了一个std::promise，并自动提供了与之关联的std::future。其最大优势在于任务对象本身是可移动的，可以方便地存入容器、传递给线程，实现执行与结果获取的解耦。

典型的使用模式是：将计算逻辑封装进std::packaged_task，然后交给std::thread或线程池去执行，最后通过其返回的future获取结果，并以此触发下一级任务。

这里有一个高频陷阱：生命周期管理。如果std::packaged_task通过引用捕获了局部变量，而任务被抛到另一个线程异步执行，当主线程函数退出、局部变量销毁后，异步任务访问的就是野指针或悬空引用。因此，务必使用值捕获，或者确保被引用对象的生命周期完全覆盖整个异步执行过程。

• std::packaged_task的模板参数是返回值类型，构造时可接受任何可调用对象（如lambda、函数指针、函数对象）。例如，std::packaged_task包装一个返回int的无参函数。
• 调用task()执行任务后，其关联的future状态会变为ready。在执行之前调用future.wait()会阻塞等待。
• std::packaged_task不可拷贝，只能移动。移动后，原对象不能再被调用，否则会抛出std::bad_function_call异常。

手动实现简易 then() 扩展：避免阻塞，用 std::thread + lambda 中转

如果非常渴望future.then([](int x) { return x * 2; })这样的流畅语法，我们可以自己动手封装一个简易版。核心思路是：接收一个原始的std::future和一个回调函数，启动一个新线程来等待前序任务完成，获取结果后调用回调，并用一个新的std::promise来包装返回值。

实现的关键在于“不阻塞调用线程”——所有耗时的get()操作都必须发生在新创建的线程中。下面是一个最简化的实现示例：

template
auto then(std::future&& f, F&& func) {
    using R = decltype(func(std::declval()));
    std::promise p;
    auto ret_fut = p.get_future();
    std::thread([f = std::move(f), func = std::forward(func), p = std::move(p)]() mutable {
        try {
            p.set_value(func(f.get()));  // 在子线程中 get()
        } catch(...) {
            p.set_exception(std::current_exception());
        }
    }).detach();  // 注意：实际项目建议用 thread pool 管理
    return ret_fut;
}

• 必须使用std::move(f)将输入future移入lambda捕获列表，因为std::future不可拷贝。
• 示例中使用.detach()分离线程，这在简单演示中可行，但在生产环境有资源泄漏风险。更稳妥的做法是使用线程池来管理线程生命周期，或者使用C++20的std::jthread实现自动联结（join）。
• 返回类型R由回调函数func的返回值推导得出。如果func返回void，则需要针对void类型特化处理p.set_value()的调用。

std::future 链式调用的真正瓶颈不在语法，而在资源管理与错误传播

许多开发者纠结于如何让代码写得像Ja vaScript Promise一样流畅，但其实在C++中，真正的挑战从来不是语法糖，而是背后扎实的资源管理与错误传播机制。

考虑一个三级任务链：f1 → f2 → f3。如果f2所在的线程因为异常而提前退出，理想情况下这个异常应该能传播到f3的future.get()调用处。但如果f2对应的std::promise对象已经被析构了，那么set_exception就无从谈起，最终程序行为将是未定义的。这类问题在简单的示例代码中很难暴露，只会在高并发或长生命周期的复杂任务中突然爆发。

• 谨慎管理std::promise的生命周期。避免让它成为短暂的栈对象。推荐的做法是在堆上分配（例如使用std::unique_ptr>），或者将其作为某个长期存活对象的成员。
• 所有需要跨线程传递的数据，其类型必须满足std::is_move_constructible（可移动构造），并且内部不应包含裸指针或非原子的共享状态。
• 尽管C++20引入了std::jthread和std::stop_token来改善线程取消问题，但标准库至今仍未内置支持链式操作的future类型。因此，不要指望仅仅通过升级语言版本就能一劳永逸地解决异步任务链的复杂性。