std::future::wait_for是最直接的超时检测方式，返回ready表示任务完成，timeout表示超时，deferred仅适用于延迟执行场景；而std::thread需配合condition_variable和共享状态手动实现，join无超时能力。
std::future::wait_for 是最直接的检测方式
子线程是否超时，本质是“任务是否在指定时间内完成”，std::future 天然支持这种语义。用 std::async 或 std::packaged_task 启动任务后，拿到 std::future 对象，调用其 wait_for 即可判断：
-
wait_for返回std::future_status::ready：任务已完成（无论成功或异常） - 返回
std::future_status::timeout：任务尚未完成，已超时 - 返回
std::future_status::deferred：仅当使用std::launch::deferred时出现，此时未启动执行，不适用于超时检测场景
示例：
auto fut = std::async(std::launch::async, []{
std::this_thread::sleep_for(std::chrono::seconds(3));
return 42;
});
if (fut.wait_for(std::chrono::seconds(2)) == std::future_status::timeout) {
// 子线程还没返回，已超时
}
std::thread + condition_variable 需手动通知完成状态
纯 std::thread 不自带完成信号，必须配合 std::condition_variable 和共享状态来实现超时检测。关键点在于：主线程不能只等“线程结束”，而要等“线程完成标志被置为 true”。
- 必须用
std::mutex保护共享变量（如bool done） - 子线程执行完后，需加锁并设置
done = true，再调用cv.notify_one() - 主线程用
cv.wait_for(lock, timeout, [&]{ return done; })—— 注意：带谓词的版本会自动处理虚假唤醒，比裸调wait_for+ 手动检查更安全
漏掉 notify_one 或忘记加锁修改 done，都会导致永远超时。
立即学习“C++免费学习笔记（深入）”；
std::thread::joinable() 和 join() 无法检测超时
joinable() 只表示线程对象是否关联一个活跃线程，join() 是阻塞等待直到线程终止——它本身不提供超时能力。强行在子线程里调 join() 会死锁；在主线程里无条件 join() 就等于放弃超时控制。
- 想用
join实现超时？不行。C++ 标准库没有join_for或类似接口 - 替代方案只有：用
std::future包装，或用condition_variable手动同步完成信号 - 若误以为
joinable()为true就代表“还在运行”，是常见误解——线程可能已结束但尚未join，此时joinable()仍为true
超时精度和系统调度会影响判断结果
wait_for 的实际等待时间通常略长于指定值，这是正常现象。Linux 下常见误差 1–4ms，Windows 下可达 15ms。这意味着：
- 设 10ms 超时，实际可能在 12ms 后才返回
timeout - 高精度场景（如实时音视频帧处理）不能依赖单次
wait_for的严格准时性 - 若业务逻辑对延迟敏感，建议用循环 + 较短超时（如 1ms）+
steady_clock累计判断，而非寄希望于一次精准等待
真正容易被忽略的不是语法，而是“谁负责设置完成信号”和“谁保证通知一定发生”——一旦子线程因异常提前退出且没走通知路径，主线程就会永远等下去，哪怕用了 wait_for。
