最常见原因是std::promise未调用set_value()或set_exception()，导致future永远未就绪；需检查分支逻辑、析构前是否调用、是否被移动失效，并用wait_for替代wait辅助定位。
std::future.wait() 一直阻塞，怎么确认是不是 promise 没 set_value？
最常见原因就是 std::promise 对象没被正确调用 set_value()（或 set_exception()），导致关联的 std::future 永远处于未就绪状态。注意：promise 和 future 是**单次写入/读取**机制，且 promise 析构前必须调用 set_xxx，否则程序会 terminate（C++11 起是 std::terminate，不是抛异常）。
调试建议：
- 在 promise 所在作用域末尾加断点，检查是否已调用
set_value()；尤其注意分支逻辑（比如 if-else、异常路径、早期 return）遗漏了 set - 用
future.wait_for(std::chrono::milliseconds(100)) == std::future_status::timeout替代无参wait()，避免卡死调试器 - 给 promise 加日志（例如构造时打印地址，set_value 前打印 "setting value for 0x..."），确认它确实被调用了
- 检查 promise 是否被移动走了（如传入 lambda 后又被 move 到线程里），原变量已为空，后续 set_value 无效
std::async 启动的 future 卡住，是不是任务根本没执行？
std::async 默认使用 std::launch::deferred 或 std::launch::async 策略，但 C++ 标准允许实现延迟启动（deferred），即直到第一次调用 get() 或 wait() 才真正执行函数——这容易让人误以为“卡住”，其实是还没开始跑。
验证和修复方法：
- 显式指定启动策略：
std::async(std::launch::async, []{ ... })，强制异步执行 - 调用
future.valid()确认 future 对象有效（如果 async 因资源不足失败，可能返回空 future） - 检查 lambda 内部是否有阻塞操作（如死锁、等待另一个未唤醒的 future、读 stdin）
- 用
future.wait_for(1s)+future.wait_status判断是超时（任务慢）、就绪（已结束）、还是 deferred（尚未执行）
多个 future 一起 wait 时卡住，是不是某个 promise 被遗忘？
组合多个 future（比如用 std::vector<:future>></:future>）时，一个 promise 漏掉 set_value 就会让整个等待逻辑挂起，但很难快速定位是哪一个。
实操技巧：
- 给每个 promise / future 绑定唯一标识（如序号、字符串标签），在 set_value 前打日志：“[task-3] setting value”
- 不要用裸循环
for (auto& f : futures) f.wait()，改用std::future_status s = f.wait_for(0ms)逐个非阻塞轮询，输出哪些 still timeout - 考虑用
std::shared_future替代多个独立 future，减少 promise 管理数量（但要注意线程安全） - 避免在 promise 构造和 set_value 之间跨线程传递裸指针或引用；优先用
std::move(promise)或std::shared_ptr<:promise>></:promise>
future.get() 卡住且程序崩溃，是不是 exception 没处理？
std::future::get() 在 promise 调用了 set_exception() 后，首次调用会**重新抛出该异常**；但如果该异常未被捕获，就会导致线程终止（对主线程是 crash）。更隐蔽的是：如果 get() 在析构期被调用（比如 future 是局部对象，get 在析构函数里），而异常未捕获，会直接 terminate。
关键检查点：
- 所有
get()必须包裹在 try-catch 中，哪怕你认为“不可能抛异常” - 确认 promise 的 set_exception 是用
std::current_exception()正确捕获并转发的，而不是手动 new 异常对象 - 避免在析构函数、atexit 回调、信号处理函数中调用
get() - 用
future.wait_for(100ms) == std::future_status::ready先判断就绪再 get，可把崩溃点从 get 提前暴露到 wait 阶段，方便定位
