std::future与std::promise需通过手动调度实现任务链式依赖：前任务用promise设值，后任务用future::wait_for轮询或回调触发，禁用阻塞get()，推荐shared_ptr包装promise以保线程安全。
std::future 和 std::promise 怎么串起有依赖的任务
靠 std::thread 硬起线程没法表达“等 A 完了再跑 B”这种依赖，得用异步通信机制。最直接的方式是让前一个任务通过 std::promise 设置结果，后一个任务用 std::future::get() 阻塞等待——但要注意，get() 会阻塞当前线程，如果在主线程里等子任务，就失去了并发意义。
实操建议：
- 把依赖链拆成独立的
std::async调用，用std::future传值：比如auto f1 = std::async(taskA); auto f2 = std::async(std::launch::deferred, [f1](){ return taskB(f1.get()); }); - 避免在工作线程里调用
get()等待另一个std::future，容易造成线程饥饿；更适合用std::future::wait_for()配合轮询，或改用基于回调的方案 -
std::promise对象必须在线程间安全传递，推荐用std::shared_ptr<:promise>></:promise>，否则移动后原对象失效，set_value()可能崩
std::condition_variable 能不能手动编排依赖顺序
可以，但很脆弱。它适合“等某个状态成立”，而不是“等某任务完成”。比如任务 B 依赖任务 A 写完某个全局变量，那可以用 std::condition_variable + std::mutex + 标志位来通知，但前提是 A 和 B 共享该状态，且没有竞态。
常见错误现象：
立即学习“C++免费学习笔记（深入）”；
- 忘记在
wait()前加lock()，或没用 while 循环检查条件（虚假唤醒） - 任务 A 修改标志后没调用
notify_one()或notify_all()，B 永远卡住 - 多个依赖任务共用同一个 condition_variable，却没区分等待条件，导致误唤醒
性能影响：频繁 notify + wait 会产生大量上下文切换，比 std::future 的无锁等待开销大得多。
有没有更接近“DAG 任务图”的轻量实现
标准库没有，但可以用 std::shared_ptr + 引用计数模拟节点依赖。每个任务包装为一个结构体，记录输入 std::vector<:shared_future>></:shared_future>，所有依赖都 wait() 完才执行本体，并用 std::promise<void></void> 标记自己完成。
关键点：
- 依赖检查必须在工作线程内做，不能在提交任务时就
wait()，否则阻塞调度器 - 用
std::shared_future是因为要被多个下游任务同时等待；普通std::future只能 move 一次 - 循环依赖不会崩溃，但会导致死锁——运行时无法检测，只能靠设计阶段规避
为什么不要用 std::jthread 或 std::latch 直接建依赖
std::jthread 只解决自动 join 和中断，不提供任务间数据流；std::latch 和 std::barrier 是同步点，适用于“多个任务一起等某个时刻”，不是“任务 A 输出喂给任务 B 输入”。硬套的话，你得自己维护中间数据、加锁、判断完成状态，反而比用 std::promise + std::future 更容易出错。
容易被忽略的地方：依赖关系本质是数据流 + 控制流，C++ 标准库只提供了控制流同步原语（如 latch、mutex），数据传递还得靠 std::promise、共享内存或消息队列。漏掉数据所有权管理，比如用裸指针传结果，多线程下大概率踩内存。
