std::this_thread::sleep_for 更推荐，因其跨平台、类型安全、语义清晰、自动处理中断，且支持 std::chrono 高可读性语法；Sleep() 则平台专属、单位固定、不兼容 chrono 类型。
std::this_thread::sleep_for 为什么比 Sleep() 更推荐
Windows API 的 Sleep() 看起来简单，但它是平台专属、不跨平台，而且单位是毫秒、不能传 std::chrono 类型——这意味着你没法直接写 sleep_for(3s) 这种可读性高的代码。C++11 起标准库提供了 std::this_thread::sleep_for，它基于 std::chrono::duration，类型安全、可移植、语义清晰。
- 用
std::this_thread::sleep_for替代Sleep()，哪怕只写 Windows 程序也建议这么做 - 必须包含头文件：
#include <thread></thread>和#include <chrono></chrono> - 注意：
sleep_for是阻塞当前线程的，别在 GUI 主线程或实时性要求高的线程里乱用 - 常见错误：传入负数时长（如
-1s），行为未定义；实际中几乎总是因为计算错误导致，建议加断言或日志校验
怎么写一个精确到毫秒的延迟（且不卡死整个程序）
“精确”是相对的——操作系统调度本身就有抖动，sleep_for 只能保证「至少休眠指定时长」，不会提前唤醒。如果你需要“非阻塞等待”，就不能用 sleep，而得结合轮询 + 高精度计时器，或者改用异步机制（比如定时器回调）。
- 最简可靠写法：
std::this_thread::sleep_for(std::chrono::milliseconds(500)) - 想写 2.5 秒？用
std::chrono::duration_cast<:chrono::milliseconds>(2.5s)</:chrono::milliseconds>不行——2.5s是std::chrono::duration<double std::ratio>></double>，而sleep_for要求整数类型时长；应改用std::chrono::duration<int std::milli>(2500)</int>或直接2500ms - 别用
std::chrono::system_clock::now()做延迟基准——它可能被系统时间调整影响；优先用std::chrono::steady_clock
Linux 下 nanosleep 和 std::this_thread::sleep_for 有啥区别
nanosleep() 是 POSIX C 函数，精度理论上到纳秒，但实际受内核调度粒度限制（通常 1–15ms）。std::this_thread::sleep_for 在 Linux 上底层大概率就调了 nanosleep()，所以二者延迟表现基本一致，没有实质性能差异。
- 用
nanosleep()得自己构造struct timespec，容易出错；sleep_for封装好了，更安全 -
nanosleep()被信号中断时会返回 -1 并设置errno == EINTR，需要手动重试；sleep_for自动处理了中断重入，无需额外逻辑 - 如果你在写嵌入式或极简环境（没 STL 线程支持），才考虑直接用
nanosleep()；否则一律走标准库
为什么 std::this_thread::sleep_until 容易用错
sleep_until 看似方便，但它的参数是绝对时间点，不是相对时长。一旦你算错了时间点（比如忘了加偏移、用了错误的 clock），线程可能立刻返回，也可能挂起几小时——而且很难 debug。
立即学习“C++免费学习笔记（深入）”；
- 典型错误：
auto tp = std::chrono::system_clock::now(); sleep_until(tp + 1s);—— 如果系统时间在休眠期间被 NTP 向后调了 10 秒，那这个“1 秒后”就变成 11 秒后了 - 正确做法：统一用
std::chrono::steady_clock，例如sleep_until(steady_clock::now() + 1s) - 除非你真在实现某种严格按 wall-clock 对齐的任务（如每整点触发），否则优先用
sleep_for，逻辑更直观、更可控
真正麻烦的不是写对一行 sleep，而是搞清你要等的是“从现在起过 X 时间”，还是“等到某个绝对时刻”。后者涉及 clock 选择、时区、闰秒、NTP 调整，一不留神就掉坑里。
