std::promise和std::future的核心用途是实现线程间单次、只读、一次性结果的同步传递，构成生产者-消费者契约：promise端调用set_value()或set_exception()写入唯一结果，future端通过get()阻塞获取该结果。
std::promise 和 std::future 不是用来“通讯”的，而是用来传递单次、只读、一次性结果的同步机制 —— 想传多条消息或双向交互，它立刻就不合适了。
std::promise 和 std::future 的核心用途是什么
它们构成一对“生产者-消费者”契约：一个线程通过 std::promise::set_value()（或 set_exception()）写入**唯一一次**结果，另一个线程通过 std::future::get() 读取该结果（带阻塞等待）。本质是“结果交付”，不是“消息队列”。
常见错误现象：std::future::get() 被调用两次 → 抛出 std::future_error: No state；试图在 promise 已 fulfill 后再次调用 set_value() → 程序终止（未定义行为）。
- 适用场景：启动异步任务并等待其最终返回值（如网络请求响应、计算结果）
- 不适用场景：实时日志推送、状态更新流、命令控制信号
- 性能影响：无锁设计，但
get()阻塞时会挂起线程，不适合高频率轮询
如何正确配对 promise/future 并避免悬空
必须由同一个 std::promise 对象生成对应的 std::future，且 promise 生命周期不得早于 future 的首次 get() 调用。
立即学习“C++免费学习笔记（深入）”；
典型错误：把局部 std::promise 对象 move 进线程，却没确保它在子线程写入前不被析构。
std::promise<int> p;
std::future<int> f = p.get_future(); // ✅ 正确配对
std::thread t([&p]() {
std::this_thread::sleep_for(100ms);
p.set_value(42); // ✅ 写入
});
t.detach(); // ⚠️ 危险！p 可能在 t 执行前就析构
- 安全做法：把
std::promisemove 进线程，或用std::shared_ptr<std::promise<T>>管理生命周期 - 切勿拷贝
std::future或std::promise（它们不可拷贝，只可移动） - 若需多个 future 观察同一结果，用
std::shared_future替代
如何处理异常和超时等待
std::future::get() 不仅能取值，还能传播 promise 端抛出的异常 —— 这是它比裸指针+互斥锁更健壮的关键点。
但默认 get() 无限等待，生产环境必须加超时保护，否则线程可能永久卡死。
- 用
wait_for()或wait_until()先判断状态：f.wait_for(500ms) == std::future_status::ready - 再调用
get()：此时不会阻塞，但依然会抛出 promise 设置的异常 - 异常路径示例：
p.set_exception(std::make_exception_ptr(std::runtime_error("timeout"))) - 注意：
wait_for()返回deferred表示 future 关联的是std::async且使用了std::launch::deferred，此时还没真正执行
为什么 std::promise 不适合替代 std::queue + mutex
因为 promise/future 缺乏“多次写入”“非阻塞尝试读取”“容量控制”“取消通知”等能力。比如你想让工作线程持续接收命令，每次收到就执行——用 promise 就得为每条命令 new 一个 pair，管理成本爆炸，且无法取消未完成的 pending promise。
对比：std::queue<Command> + std::mutex + std::condition_variable 天然支持多生产者、多消费者、带条件唤醒、可中断等待。
- promise/future 是“一锤子买卖”，适合 request-response 模式
- std::queue + mutex 是“流水线”，适合 event-driven 或 pipeline 场景
- 混淆二者最常踩的坑：用 promise 实现心跳检测，结果发现无法重置、无法批量处理、无法区分“超时”和“未启动”
真正复杂的线程协作，往往要组合多种原语：promise/future 做初始握手，queue + cv 做后续数据流，atomic flag 做开关控制 —— 单靠 promise 撑不起整个通信模型。
