clock_nanosleep定时不准因依赖CLOCK_MONOTONIC且受调度延迟、优先级与负载影响，仅适用于软实时；需用TIMER_ABSTIME模式、提升调度优先级并减少干扰才能逼近亚毫秒精度。
clock_nanosleep 在 Linux 上为什么定时不准？
因为 clock_nanosleep 默认用的是 CLOCK_MONOTONIC，它不保证唤醒的“即时性”——内核调度延迟、进程优先级、负载都会让实际唤醒时间漂移几毫秒甚至更久。尤其在非实时内核、普通用户态进程里，clock_nanosleep 只能当“软实时”用，别指望它稳定控到 ±10μs。
- 必须用
TIMER_ABSTIME模式 + 手动计算下次绝对时间点，否则连续调用会累积误差 - 避免在循环里直接
clock_nanosleep(..., 1000000)（休眠 1ms），这等于把误差滚雪球 - 如果需要 sub-ms 级精度，得配合
sched_setscheduler提升进程调度优先级，且运行在无桌面、少中断干扰的环境
Windows 上 WaitableTimer 怎么设才能接近硬件精度？
CreateWaitableTimerEx 是唯一能真正启用高精度模式的入口，但默认创建的 timer 是“低分辨率”的——即使你传了 10000ns 的 liDueTime，系统也可能四舍五入到 15.6ms（典型 multimedia timer 分辨率）。
- 必须指定
CREATE_WAITABLE_TIMER_HIGH_RESOLUTION标志，否则白搭 -
liDueTime是 100ns 单位的负值（相对当前时间），写成-100000表示 10ms 后触发，别漏负号 - 搭配
timeBeginPeriod(1)可强制系统 timer 分辨率提至 1ms，但这是全局副作用，退出前得配对调用timeEndPeriod(1)
跨平台时该选哪个底层机制？
没有银弹。Linux 下 clock_nanosleep 更轻量、无需句柄管理；Windows 下 WaitableTimer 支持异步 I/O 关联和 APC，更适合集成进 IOCP 模型。但两者都绕不开同一个事实：C++ 标准库的 std::this_thread::sleep_for 底层就是封装了它们，精度完全取决于 OS 实现，不是靠换语言能解决的。
- 不要试图用
std::chrono::high_resolution_clock来“校准”休眠——它的精度≠调度器精度 - 若任务周期固定（如每 5ms 采样一次），建议用单调递增的绝对时间点驱动，而非相对休眠
- 调试时用
perf record -e sched:sched_wakeup（Linux）或Windows Performance Recorder看真实唤醒延迟分布，比看代码更可靠
为什么用 std::condition_variable::wait_until 还是不准？
因为 std::condition_variable::wait_until 底层仍走的是 pthread_cond_timedwait 或 Windows 的 SleepConditionVariableCS，它们本身就不承诺高精度——标准只要求“不早于指定时间返回”，晚多少没上限。而且条件变量还多了一层锁竞争开销。
立即学习“C++免费学习笔记（深入）”；
- 别把它当定时器用，只适合“等某个业务条件 + 最多忍耐多久”的场景
- 即使你传了
steady_clock::now() + 100us，实际可能 2ms 后才返回，尤其在锁争抢激烈时 - 真要硬实时，就得绕过 C++ 标准库，直连系统 API，并接受需要 root/Admin 权限的事实
nanosleep 或 SetWaitableTimer 的参数都只是自我安慰。 
