std::future_status只有ready、timeout、deferred三个值：ready表示结果就绪可安全get；timeout仅说明等待超时，任务未必失败，不可立即get；deferred表示延迟执行，首次get才触发任务。
std::future_status 的取值含义和常见误用
直接看 std::future_status 枚举值：它只有三个合法值——std::future_status::ready、std::future_status::timeout、std::future_status::deferred。很多人误以为 timeout 表示“任务失败”或“被取消”，其实它只是说明 wait_for() 或 wait_until() 在指定时间内没等到结果，任务可能仍在运行、也可能已结束但未被取走。
关键点：没有 std::future_status::cancelled —— C++ 标准库不提供原生取消机制，超时 ≠ 取消。
-
ready：结果已就绪（包括异常），可安全调用get() -
timeout：等待时间耗尽，future状态未变，此时不能调用get()（会阻塞） -
deferred：对应std::launch::deferred启动策略，函数尚未执行，调用get()才真正执行
wait_for() 返回 timeout 之后还能做什么
返回 std::future_status::timeout 后，future 依然有效，但必须避免重复或错误访问：
- 不能立刻调用
get()—— 会阻塞直到结果就绪（失去超时意义） - 可再次调用
wait_for()做轮询，例如每 100ms 检查一次 - 若底层任务支持外部中断（如通过共享
std::atomic<bool></bool>控制循环），此时可设置退出标志 - 注意：多次
wait_for()不影响future生命周期，但别在析构后访问
示例片段：
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
立即学习“C++免费学习笔记（深入）”；
auto fut = std::async(std::launch::async, []{ std::this_thread::sleep_for(2s); return 42; });
auto status = fut.wait_for(1s);
if (status == std::future_status::timeout) {
// 此时不能 fut.get()！
std::cout << "still running...\n";
// 可选择继续等、记录日志、或触发清理逻辑
}
wait_for() 和 wait_until() 的参数差异与精度陷阱
wait_for() 接受相对时长（std::chrono::duration），wait_until() 接受绝对时间点（std::chrono::time_point）。两者都可能因系统调度、时钟精度导致“提前返回 timeout”。
- Windows 上
std::chrono::steady_clock分辨率通常为 15ms 左右，wait_for(1ms)实际可能等 15ms 后才返回timeout - 不要用
wait_for(0s)当“非阻塞检查”——标准未保证其立即返回，某些实现会退化为wait_for(1ns)并仍可能超时 - 跨线程场景下，
wait_for()返回timeout不能推断任务一定还在跑；它可能刚完成、正被其他线程取走get()，而你恰好错过
如何配合 async/launch 策略判断是否真超时
std::async 默认使用 std::launch::async | std::launch::deferred，这意味着即使写了 wait_for()，也可能遇到 deferred 状态而非 timeout —— 这不是超时，是还没启动。
- 明确指定
std::launch::async才能确保异步执行，排除deferred干扰 - 若需可靠超时控制，避免混合 launch 策略；统一用
std::thread+std::promise更可控 - 注意：
std::future析构时若状态为deferred，会同步执行延迟函数——这会让析构阻塞，意外破坏超时逻辑
所以，检查超时前先确认状态不是 deferred：
if (status == std::future_status::deferred) {
// 必须手动 get() 启动，或改用 std::launch::async
}
实际项目里，std::future_status::timeout 很少单独决定业务逻辑，它只是个信号——后续动作取决于你能否干预任务本身。多数时候，真正的“超时处理”得靠外部协作机制，而不是仅靠 future 状态。 
