std::future_status的三个取值描述future就绪状态：ready表示结果已就绪（含异常），timeout表示未超时但暂未就绪，deferred表示延迟执行、调用get才触发；非阻塞轮询须用wait_for配合状态判断，不可反复调用get。
std::future_status 的三个取值到底代表什么状态
它不是“成功/失败”二元判断，而是描述 std::future 当前是否就绪的瞬时快照。常见误解是把 std::future_status::timeout 当作错误——其实它只是“还没好”，不抛异常、不改变 future 状态。
-
std::future_status::ready：结果已就绪（无论函数正常返回还是抛异常） -
std::future_status::timeout：等待超时，future 仍有效，可继续调用wait_for或改用wait_until -
std::future_status::deferred：任务被标记为std::launch::deferred，尚未执行；此时调用get()才真正触发执行
用 wait_for 实现非阻塞轮询的正确姿势
别直接在循环里无休止调用 get()——那会阻塞。必须用 wait_for 检查状态，再决定是否取值。典型场景是 GUI 线程或游戏主循环中避免卡顿。
- 传入的
std::chrono::duration是最大等待时间，不是固定休眠时长 - 返回
std::future_status::timeout后，future 依然合法，可以下次再试 - 不要对同一个 future 多次调用
get()：第一次调用后 future 变成 invalid，再调会抛std::future_error
示例：
auto fut = std::async(std::launch::async, []{ std::this_thread::sleep_for(2s); return 42; });
while (fut.wait_for(100ms) == std::future_status::timeout) {
// 做点别的事：刷新界面、处理输入、发心跳…
}
int result = fut.get(); // 此时 guaranteed ready
wait_for 和 wait_until 的关键区别与选型
两者都返回 std::future_status，但语义不同：wait_for 是相对等待，wait_until 是绝对截止时间。在需要严格对齐某时间点（比如帧同步、定时上报）时，wait_until 更可靠。
立即学习“C++免费学习笔记（深入）”；
-
wait_for(100ms)：从调用时刻起最多等 100ms，但每次调用都重置计时起点 -
wait_until(deadline)：一直等到deadline时间点，适合做带容错的 deadline 控制 - 注意系统时钟精度：Windows 上
steady_clock更稳定，避免用system_clock做超时基准
容易踩的坑：异常、移动语义和线程安全
future 本身不是线程安全的——不能跨线程同时调用 wait_for 和 get()。更隐蔽的问题是：异步函数内部抛异常，wait_for 返回 ready 后，get() 才真正 rethrow。
- 如果异步任务抛异常，
wait_for仍可能返回std::future_status::ready，别跳过get()调用 - move 构造 future 后，原对象变为 valid == false，再对其调用
wait_for会抛std::future_error（code: no_state） - 别用
std::shared_future替代std::future来“规避”移动问题——它解决的是多消费者场景，不解决单个 future 的生命周期管理
超时控制真正的复杂点不在 API 调用，而在怎么定义“业务意义上的超时”：是整个任务超时，还是某次轮询间隔超时？后者容易忽略状态残留和重复提交风险。
