必须用std::this_thread::sleep_for实现跨平台可靠延时，因其基于系统时钟、行为稳定且保证至少休眠指定时长；windows sleep粗粒度且linux不可用，且sleep_for需配合std::chrono::duration（如milliseconds(500)），不可传裸整数。
std::this_thread::sleep_for 为什么比 Windows Sleep 更可靠
跨平台延时必须用 std::this_thread::sleep_for，它基于系统时钟，精度和行为稳定；而 Windows 的 Sleep 是粗粒度 API，实际休眠常比指定时间长得多，且 Linux 下根本不可用。
关键点：它接受的是「持续时间」（std::chrono::duration），不是毫秒整数，不能直接传 1000 这种裸数字。
- 必须搭配
std::chrono类型，比如std::chrono::milliseconds(500)、std::chrono::seconds(2) - 底层调用依赖系统调度器，无法保证精确到纳秒级，但能保证「至少休眠这么久」
- 若线程被中断（如收到信号或被
std::thread::interrupt()，C++20 前不支持），不会提前返回，这点和 POSIXnanosleep不同
nanoseconds 要小心——不是所有场景都该用它
std::chrono::nanoseconds 是合法类型，但绝大多数硬件和 OS 无法真正响应纳秒级休眠请求。直接写 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<long long milli></long>，不是整数 - 混用单位易出错：比如
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，而是判断「这里到底该不该睡，睡了谁来负责唤醒，睡错了会不会卡死整个流程」。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
