std::this_thread::sleep_for 是跨平台延时首选，需显式指定 chrono 单位（如 milliseconds），避免混用 win32 sleep；注意线程存活、锁状态及系统调度精度限制。
用 std::this_thread::sleep_for 最省心
标准库已经提供了跨平台的延时方案，std::this_thread::sleep_for 是首选。它不依赖系统 API，编译器（GCC/Clang/MSVC）都支持 C++11 起的实现，Windows、Linux、macOS 下行为一致。
常见错误是传错时间单位：比如写成 sleep_for(1000) 以为单位是毫秒——其实参数是 std::chrono::duration，必须显式指定单位：
std::this_thread::sleep_for(std::chrono::milliseconds(1000)); // ✅ 正确 std::this_thread::sleep_for(1000); // ❌ 编译失败
- 推荐统一用
std::chrono::milliseconds或std::chrono::microseconds，避免手算纳秒 - 如果延时精度要求不高（>10ms），直接用
milliseconds；高精度场景注意：Linux 的clock_nanosleep和 Windows 的Sleep底层调度粒度不同，实际唤醒可能有几毫秒偏差 - 不要在信号处理函数或实时线程里依赖它做精确周期控制——它不保证硬实时
Windows 下别碰 Sleep，除非你明确要 Win32 专用
Win32 的 Sleep 函数虽然简单，但和 POSIX 的 nanosleep 行为不兼容：前者单位是毫秒且会把 0 解释为“让出当前时间片”，后者单位是纳秒且 0 表示“不休眠”。混用容易导致跨平台构建失败或逻辑错乱。
- 如果你写了
#ifdef _WIN32+Sleep，又忘了加#include <windows.h></windows.h>，MSVC 会报undeclared identifier 'Sleep' - 即使加了头文件，
Sleep(0)在 Windows 上会 yield，但在 Linux 下没对应等价写法，移植时极易漏改 - 除非你在写纯 Windows 工具（比如 .exe 插件），否则没必要绕过标准库去调用它
遇到 std::this_thread::sleep_for 不生效？先查线程状态
延时“没反应”八成不是函数问题，而是线程本身被阻塞或已结束。最典型的场景是：主线程退出后，其他线程还没执行到 sleep_for 就被强制终止了。
立即学习“C++免费学习笔记（深入）”；
- 确保调用
sleep_for的线程还活着——检查是否在std::thread对象析构前调用了join()或detach() - 如果线程里有锁（
std::mutex），确认没在持锁状态下调用sleep_for，否则可能掩盖死锁现象（看起来像“卡住”，其实是等锁） - 某些嵌入式或容器环境（如 musl libc）对
std::chrono::steady_clock支持不完整，若编译报错no member named 'steady_clock'，说明标准库实现不全，得降级用system_clock（但要注意它可能被系统时间调整影响）
需要微秒级以下精度？别指望 sleep_for
所有主流操作系统内核的定时器分辨率都在毫秒级（Windows 默认 15.6ms，Linux CLOCK_MONOTONIC 通常 1–15ms），std::this_thread::sleep_for(std::chrono::nanoseconds(100)) 实际延时仍是毫秒级，且可能比预期长得多。
- 想测真实延时？用
std::chrono::steady_clock::now()前后打点，别信理论值 - 真要 sub-millisecond 响应（比如音频采样同步），得用忙等待（
while循环 +rdtsc或clock_gettime(CLOCK_MONOTONIC_RAW)），但会吃满 CPU，且跨平台更麻烦 - 多数业务场景里，“睡够 10ms 以上”就足够，强行压到微秒反而让代码变脆弱
跨平台 Sleep 的核心就一条：信标准库，别自己造轮子。难的是理解底层调度限制，而不是写几行代码。
