windows 不存在纳秒级sleep：sleep()仅支持毫秒参数，std::this_thread::sleep_for(nanoseconds)底层仍受限于系统15.6ms计时器粒度，实际休眠常为0ns或≥15ms；高精度需分层处理——≥10ms用sleep，1–10ms配合timebeginperiod，
因为 Windows 的 Sleep 函数根本不接受纳秒参数，所谓“sleep(纳秒级参数)”本身就是一个伪命题——它连语法都不合法，更谈不上精度是否靠谱。
Windows 的 Sleep 只认毫秒，没有“纳秒接口”
Windows API 中的 Sleep() 原型是：
VOID Sleep(DWORD dwMilliseconds);
参数类型是 DWORD（无符号32位整数），单位固定为毫秒。你传 Sleep(1) 是合法的，传 Sleep(1000) 表示 1 秒，但传 Sleep(1000000) 并不等于 1 秒——它只是个超大毫秒数（约 16 分钟），和纳秒毫无关系。C++ 标准库里的 std::this_thread::sleep_for(std::chrono::nanoseconds(100)) 虽然能编译，但底层仍调用的是 Windows 的 Sleep 或类似机制，纳秒值在进入系统调用前就被向下取整或截断。
系统计时器分辨率才是真正的天花板
即使你绕过 Sleep、用 QueryPerformanceCounter + 自旋来“模拟”纳秒延迟，也受限于硬件与系统：
- 默认 Windows 计时器粒度是 15.6ms（由 64Hz 系统时钟决定），哪怕你调用
timeBeginPeriod(1)，也只能把下限压到 1ms 左右，且需管理员权限、配对调用timeEndPeriod，否则长期拖累系统功耗和调度公平性 - CPU 频率动态缩放（Turbo Boost / P-states）、跨核迁移、中断延迟、DPC 延迟等都会让实际唤醒时间波动在 数十微秒甚至毫秒级
- RDTSC/RDTSCP 指令读取的时间戳虽达纳秒级，但本身执行就要 20–40ns，且在非固定频率、非绑核场景下误差不可控
“纳秒级 sleep”在通用 Windows 上不存在
操作系统不是 FPGA，内核调度、中断处理、电源管理、硬件抽象层共同构成一道天然滤波器。真实场景中：
- 请求
sleep_for(100ns)→ 实际休眠常为 0ns（直接返回）或 ≥15ms - 请求
sleep_for(1μs)→ 多数情况被截断为 0，或退化为忙等+调度让出，结果不可预测 - 只有在实时扩展（如 Windows IoT Enterprise + PREEMPT_RT 类补丁）、专用驱动、禁用所有后台服务、绑定单核、关闭 C-states 的极端条件下，才可能逼近 10–50μs 级别，仍远非“纳秒”
那该怎么写高精度等待？
务实做法是按需分层：
-
≥ 10ms：直接用
Sleep()，简单可靠 -
1–10ms：先
timeBeginPeriod(1)，再Sleep(1)，注意资源清理 - ：放弃休眠，改用
QueryPerformanceCounter自旋，但必须绑核、禁 turbo、测准循环开销并校准 -
绝对不要：把
std::chrono::nanoseconds当作可兑现承诺，或在日志/调试中打印“已休眠 123ns”来自欺欺人
