最稳妥的休眠方式是std::this_thread::sleep_for，它接受std::chrono时长、不依赖系统时钟偏移、类型安全且跨平台；避免使用已弃用的C风格sleep/usleep，因其非标准、精度模糊且Windows不支持usleep。
直接说结论：用 std::this_thread::sleep_for 最稳妥，它接受一个 std::chrono 时长，不依赖系统时钟偏移，比 sleep_until 更常用、更直观。
为什么不用 sleep 或 usleep？
这些是 C 风格的 POSIX 函数（sleep 秒级、usleep 微秒级），在 C++11 后已不推荐：它们不是标准 C++，跨平台性差（Windows 不支持 usleep），且精度和语义模糊。C++ 标准库提供了类型安全、可读性强的替代方案。
常见错误现象：usleep(1000) 看似休眠 1 毫秒，实际是 1000 微秒 → 容易误算；在 Windows 编译直接报错 unresolved external symbol usleep。
- 必须包含头文件：
#include <thread></thread>和#include <chrono></chrono> - 不需要链接额外库（如 pthread），
std::this_thread::sleep_for是标准库内置实现 - 休眠期间线程让出 CPU，但不释放持有的互斥锁（这点和
std::condition_variable::wait有本质区别）
sleep_for 的典型用法和参数陷阱
它接收一个 std::chrono::duration 类型，比如 std::chrono::milliseconds(500)。关键点在于：不能传裸数字，也不能混用不同精度的 duration（比如把 seconds 直接赋给 milliseconds 变量，会编译失败）。
立即学习“C++免费学习笔记（深入）”；
正确示例：
#include <thread> #include <chrono> <p>std::this_thread::sleep_for(std::chrono::milliseconds(100)); std::this_thread::sleep_for(2s); // C++14 起支持字面量运算符，需 #include <chrono> std::this_thread::sleep_for(std::chrono::duration_cast<std::chrono::milliseconds>(1.5s));
- 避免写
sleep_for(100)—— 编译不过，缺少 duration 类型信息 -
100ms和std::chrono::milliseconds(100)等价，但前者需 C++14+ 且开启std::literals::chrono_literals（通常默认可用） - 如果计算动态时长，优先用
duration_cast显式转换，避免隐式截断（例如把microseconds转milliseconds时丢精度）
休眠被中断怎么办？sleep_for 会抛异常吗？
不会。std::this_thread::sleep_for 是“尽力休眠”，不响应中断请求（如 std::thread::interrupt() 已被弃用），也不抛异常。即使系统时间被大幅调整（如 NTP 同步跳变），它仍按相对时长等待，行为稳定。
但它可能因系统调度延迟而略长于指定时间（这是所有用户态休眠的共性，非 bug）。如果你需要「绝对截止时间」或「可取消等待」，应改用 std::condition_variable::wait_until 配合 predicate 和 mutex。
- 不要指望
sleep_for做超时等待 I/O 或锁 —— 它不具备唤醒机制 - 调试时发现休眠远超预期？先检查是否卡在了前序的
mutex.lock()或死锁，而非sleep_for本身 - 高精度定时场景（如音频同步）慎用，它不保证 sub-millisecond 级别准时性
真正容易被忽略的是：休眠时长的单位语义必须和业务逻辑对齐。比如网络重试退避策略里写 sleep_for(2 * base_delay)，如果 base_delay 是 std::chrono::seconds，但乘法结果被误存为 int，就彻底丢失了 duration 类型安全 —— 这类问题编译期无法捕获，运行时才表现异常。
