std::this_thread::sleep_for 不够准，因其依赖系统调度器且为“至少休眠”，受时钟分辨率（如Windows默认15.6ms）、调度延迟等影响，实测误差可达毫秒级；高精度场景应改用clock_nanosleep（Linux）或QueryPerformanceCounter+自旋（Windows）。
为什么 std::this_thread::sleep_for 不够准？
因为底层依赖系统调度器，实际挂起时间常比请求值长——尤其在负载高、线程优先级低或未启用实时调度的普通 Linux/Windows 上。sleep_for 是“至少休眠”，不是“精确休眠”。常见现象是：请求 1ms，实际延迟 15ms；请求 100μs，结果根本没停住，直接跳过。
根本原因在于：系统时钟中断频率有限（如 Windows 默认 15.6ms 分辨率，Linux HZ 通常 250 或 1000），且线程唤醒后还需排队等 CPU 调度。所以别指望靠它做音频同步、高频采样触发或硬件握手这类事。
用 clock_nanosleep（Linux）绕过调度器抖动
它支持 CLOCK_MONOTONIC + TIMER_ABSTIME 模式，能避开系统时钟更新和调度延迟带来的累积误差，实测可压到 ±5μs 内（需配合适当优先级）。
- 必须用绝对时间（
clock_gettime(CLOCK_MONOTONIC, &ts)获取起点，再加偏移构造目标时间） - 调用前建议设线程策略：
sched_setscheduler(0, SCHED_FIFO, ¶m)，否则仍受普通调度干扰 - 注意：
clock_nanosleep可被信号中断，需检查返回值是否为-1且errno == EINTR，然后重试
struct timespec ts;
clock_gettime(CLOCK_MONOTONIC, &ts);
ts.tv_nsec += 50000; // 50μs
if (ts.tv_nsec >= 1000000000) {
ts.tv_sec++;
ts.tv_nsec -= 1000000000;
}
clock_nanosleep(CLOCK_MONOTONIC, TIMER_ABSTIME, &ts, nullptr);
Windows 上用 QueryPerformanceCounter + 自旋补偿
系统 Sleep 系列函数（Sleep、WaitForSingleObject）最低分辨率仍是毫秒级，低于 1ms 基本无效。可行方案是：先 Sleep 到离目标还剩 100–200μs，再用高精度计数器自旋等待剩余时间。
立即学习“C++免费学习笔记（深入）”；
- 自旋不能无脑
while (now ，必须用 <code>QueryPerformanceCounter读取，QueryPerformanceFrequency换算成纳秒 - 自旋期间建议插入
YieldProcessor()（或_mm_pause()）减少功耗和抢占冲突 - 慎用：自旋会占满一个逻辑核，多线程下易引发争抢，只适合短时（
跨平台封装要注意的三个硬伤
别试图写个“通用高精度 sleep”头文件就一劳永逸——不同系统对“高精度”的定义和能力边界差太多。
- Linux 下
clock_nanosleep需要POSIX_TIMERS和RT权限（非 root 可能失败），而 Windows 的自旋方案在虚拟机里几乎失效（QueryPerformanceCounter虚拟化开销大） - 即使同一台机器，开启 CPU 频率调节（如 Intel SpeedStep）也会让自旋循环的实际耗时飘忽不定
- 所有方案都绕不开内核态到用户态的上下文切换成本，真正稳定 ≤1μs 的延迟，得进内核模块或用 XDP/eBPF 这类机制——那已经不是 C++ 应用层该碰的了
真要压到微秒级，得接受：要么绑核+关中断（嵌入式/Linux RT），要么换语言（Rust 的 spin_sleep crate 有更细粒度控制），要么承认应用层就是做不到，把逻辑移到 FPGA 或专用协处理器上。
