必须用std::this_thread::sleep_for实现跨平台可靠延时，因其基于系统时钟、行为稳定且保证至少休眠指定时长；Windows Sleep粗粒度且Linux不可用，且sleep_for需配合std::chrono::duration（如milliseconds(500)），不可传裸整数。
先说几个核心判断。
跨平台延时，必须用 std::this_thread::sleep_for。它基于系统时钟，行为稳定，保证至少休眠指定时长。而 Windows 的 Sleep 是粗粒度 API，实际休眠时长往往比指定时间长得多，而且 Linux 下根本不可用——直接出局。
关键点在于：sleep_for 接受的是“持续时间”（std::chrono::duration），不是毫秒整数。所以不能直接传 1000 这种裸数字。
- 必须搭配
std::chrono类型，比如std::chrono::milliseconds(500)、std::chrono::seconds(2)。 - 底层调用依赖系统调度器，无法保证精确到纳秒级，但能保证“至少休眠这么久”。
- 如果线程被中断（比如收到信号或被
std::thread::interrupt()，C++20 前不支持），不会提前返回。这点和 POSIX 的nanosleep不同。
nanoseconds 要小心——不是所有场景都该用它
std::chrono::nanoseconds 是合法类型，但绝大多数硬件和操作系统无法真正响应纳秒级休眠请求。直接写 sleep_for(nanoseconds(1000))（即 1 微秒），大概率等同于“立刻返回”或触发最小调度粒度（通常是 1–15ms）。
典型误用：sleep_for(nanoseconds(500)) 想实现 0.5 微秒延时——这在用户态程序中毫无意义。
- 仅在高精度计时、性能打点、或配合 busy-wait 做微调时，才需要 nanoseconds。
- 真实延时建议从
microseconds(100)起步测试，再观察实际耗时（可用steady_clock::now()测量）。 - Linux 下
nanosleep系统调用本身也只保证“不早于”指定时间唤醒，内核仍可能延迟。
换句话说，如果你只是想“等一会儿”，请老老实实从毫秒级往上写。
常见错误：忘记 std::chrono::duration 的隐式转换陷阱
下面这段代码编译失败：
sleep_for(100); // ❌ 错误：没有匹配的函数
原因很简单：sleep_for 参数类型是模板化的 Rep, Period，编译器无法从整数推导出单位。
- 正确写法只有显式构造：
sleep_for(milliseconds(100))、sleep_for(100ms)（C++14 起支持字面量）。 100ms是std::chrono::milliseconds类型，本质是duration，不是整数。- 混用单位容易出错：比如
sleep_for(seconds(1) + milliseconds(500))可行，但sleep_for(1 + 500ms)会编译失败（整数 + duration 不自动提升）。
这个陷阱看着小，但确实容易让人抓狂。
实战建议：延时逻辑别裸写在主线程里
如果只是想“等 2 秒再继续”，用 sleep_for 没问题。但一旦涉及 UI 响应、网络等待、或需要中途取消，就必须换方案。
- GUI 程序（Qt/Win32）用定时器（
QTimer/SetTimer），避免阻塞消息循环。 - 异步任务中优先用
std::async+std::future::wait_for，或 C++20 的std::jthread配合 stop_token。 - 调试时别依赖 sleep_for 测性能：它的开销本身不稳定，尤其短延时下，测量误差远大于目标值。
说到底，真正难的不是怎么写那一行 sleep_for，而是判断“这里到底该不该睡，谁来负责唤醒，睡错了会不会卡死整个流程”。延时逻辑的设计，比代码本身重要得多。
