应使用 wait_for(std::chrono::milliseconds(0)) 检查异步任务是否完成：返回 ready 表示已完成，timeout 表示运行中，deferred 表示延迟执行；需显式指定 std::launch::async 以避免不确定性，且应优先使用 std::async 而非手动管理 std::promise。
如何用 std::future 检查异步任务是否完成
直接调用 wait_for 或 wait_until 是最常用、最可靠的方式。不能靠轮询 valid() 或猜测状态——valid() 只表示 future 是否关联有效共享状态，和“是否完成”无关。
典型错误是写成：if (fut.valid()) { /* assume done */ }，这完全不可靠；valid() 在刚构造完、还没执行时也可能返回 true（比如从 std::async 获取后）。
-
wait_for(std::chrono::milliseconds(0))返回std::future_status::ready才代表已完成 - 返回
std::future_status::timeout表示仍在运行（注意：不是失败） - 返回
std::future_status::deferred表示任务被延迟执行（仅当使用std::launch::deferred时出现）
std::async 默认启动策略对状态检查的影响
默认策略 std::launch::async | std::launch::deferred 会让系统自行决定是立即启动还是延迟执行，这会导致 wait_for(0) 返回 deferred 而非 timeout，进而让状态判断逻辑意外跳过实际运行检查。
如果你需要确定性行为（比如轮询检测），必须显式指定启动方式：
- 用
std::async(std::launch::async, ...)强制后台线程执行 →wait_for(0)要么ready，要么timeout - 避免只传函数对象不带 launch 策略，否则无法预测
wait_for的返回值含义 - 若用
deferred，get()才真正触发执行，wait_for永远返回deferred
多线程环境下读取状态的线程安全边界
std::future 的 wait_for、wait_until、get 都是线程安全的，但仅限于“单个 future 对象”——同一个 std::future 实例不能在多个线程中并发调用 get()，否则未定义行为（get() 是一次性消费操作）。
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
常见误用：
- 把同一个
std::future对象拷贝给多个线程，然后都调用get()→ 第二次调用会抛std::future_error（错误码no_state） - 正确做法：用
std::shared_future替代，它允许多次get()，且线程安全 -
wait_for可以多次调用，无论是否shared_future，只要 future 还有效
为什么不用 std::promise 自己管理状态
除非你需要精细控制完成时机（比如跨回调链手动设置结果），否则没必要绕过 std::async 去手配 std::promise + std::future。手动管理容易漏掉异常传播路径——std::promise::set_exception 必须显式调用，而 std::async 会自动捕获并封装异常到 future 中。
如果真要用 promise：
- 确保每个 promise 只调用一次
set_value或set_exception，重复调用会抛std::future_error（promise_already_satisfied） - 不要在 promise 析构前忘记设置值，否则对应 future 调用
get()会永久阻塞 - 状态检查仍得靠 future 侧的
wait_for，promise 本身不提供“是否已设置”的查询接口
异步状态不是布尔标志，而是与执行模型强耦合的时序契约；漏掉 launch 策略、混用 future 类型、或忽略异常传递路径，比写错条件判断更容易导致卡死或崩溃。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
