std::promise 和 std::future 是一对协作组件，用于在线程间安全传递单次结果：promise 负责 set_value()，future 负责 get()，二者共享控制块，仅能各操作一次，重复调用抛出 future_error；promise 不可共享，通常 move 或用 shared_ptr 管理，future 不可拷贝，多处等待需 shared_future；get() 阻塞，应交由工作线程或配合 wait_for/wait_until 使用；async 封装了 promise/future/线程，适合简单场景，复杂逻辑建议手动控制；跨线程使用时须确保 promise 生命周期长于 future 等待，否则触发 broken_promise 错误。
std::promise 和 std::future 是什么关系
它们是一对协作组件，用于在线程间安全传递单次结果：std::promise 负责“设置值”，std::future 负责“获取值”。不是管道，也不是队列——只能 set_value() 一次，get() 也仅能调用一次，重复调用会抛出 std::future_error（错误码为 future_errc::no_state 或 future_errc::future_already_retrieved）。
常见误用是把 std::promise 当作可重用的通信通道，比如在循环里反复 set_value() ——这会直接崩溃或未定义行为。
-
std::promise对象本身不共享；通常 move 到线程中，或通过std::shared_ptr管理生命周期 -
std::future不可拷贝，只能移动；若需多处等待，得用std::shared_future - 一旦
promise.set_value()被调用，关联的future.wait()或future.get()就能返回（或立即返回）
如何避免 future.get() 阻塞主线程
std::future::get() 是阻塞调用，且无超时机制（除非用 std::future::wait_for() 或 wait_until()）。如果在 GUI 主线程或响应式服务线程里直接调用，会导致界面卡死或请求超时。
正确做法不是“避免 get”，而是“控制在哪调用”：
立即学习“C++免费学习笔记（深入）”；
- 把
future交给工作线程处理，例如用std::thread或线程池执行future.get() - 用
std::future::wait_for(std::chrono::milliseconds(0))做非阻塞轮询（但轮询效率低，仅适合简单场景） - 更推荐组合
std::packaged_task+std::thread，让任务完成时自动触发回调逻辑
示例：启动异步计算并立即返回 future，后续在合适时机（如定时器、IO 完成后）再 get()：
std::promise<int> p;
auto f = p.get_future();
std::thread([&p]{ p.set_value(42); }).detach();
// 此处可做其他事...
int result = f.get(); // 这里才真正等待
std::async 与手动 promise/future 的取舍
std::async 内部其实就封装了 std::promise + std::future + 线程/任务调度，但它隐藏了中间控制权。是否用它，取决于你是否需要：
- 延迟启动：默认
std::async使用std::launch::async | std::launch::deferred策略，可能延迟到get()才执行；若需立刻派生线程，必须显式传std::launch::async - 异常传播：
std::async中抛出的异常会被捕获并存入future，get()时重抛；手动 promise 需自己调用set_exception() - 资源归属：
std::async返回的future在析构时，若仍关联未完成的异步任务，会阻塞等待——这是很多人踩坑的地方（比如局部future提前析构）
所以，复杂流程（如任务链、条件分支、取消支持）建议手写 promise/future；简单“扔个函数去算，回头要结果”，std::async 更简洁。
跨线程传递 future 时的生命周期陷阱
最隐蔽的问题是：promise 对象被销毁，但还有线程在等它的 future ——此时 future.get() 会抛出 std::future_error（future_errc::broken_promise）。
根本原因：promise 和 future 共享一个隐式控制块（control block），promise 析构时若没人 set 过值，该控制块就标记为 broken。
- 永远不要让
std::promise是栈对象且作用域早于等待它的线程 - 若 promise 需被多个线程访问（如被回调函数设置值），用
std::shared_ptr<std::promise<T>>管理 - 在回调中 set_value 前，先检查 promise 是否还有效（可通过
promise.get_future().valid()判断，但这只是弱检查；更稳妥的是确保 shared_ptr 未空）
这个 broken_promise 错误不提示具体哪条线程、哪个 promise 出问题，调试时容易误判为逻辑错误而非生命周期问题。
