Windows下Sleep(0)无法实现1微秒精度，实际延迟在0.5–15ms间波动；需用RDTSC忙等待配合CPU绑定与频率锁定，误差可压至±50ns，但“精确1微秒”是伪命题。
Windows下Sleep(0)根本不能做到1微秒精度
Windows的Sleep()最小调度单位是毫秒级，即使传入0，实际也只让出当前时间片，无法控制延迟长度；实测在多数系统上平均延迟在0.5–15ms之间波动，完全不可靠。真正需要微秒级停顿（比如硬件同步、信号采样对齐），必须绕过内核调度器，直接操作CPU周期或使用高精度计时器忙等。
用RDTSC指令做忙等待最直接但有坑
RDTSC读取CPU时间戳计数器（TSC），配合循环等待可实现亚微秒级控制。但要注意：
- 现代CPU可能禁用或非恒定频率TSC（如启用了Turbo Boost或P-state切换），导致
RDTSC结果不线性——需先用cpuid序列化并检查IA32_TSC是否恒定（rdmsr 0x30查IA32_TSC_DEADLINE或用__readtsc()前加__cpuid(0)） - 编译器可能优化掉空循环，必须用
volatile或_mm_pause()抑制优化 - 单次
RDTSC开销约30–50个周期（≈10–20ns），1微秒≈1000ns，所以目标延迟至少预留20–30次循环缓冲
示例片段（x64 MSVC）：
uint64_t start = __rdtsc();
uint64_t end = start + target_cycles; // target_cycles ≈ 1us × CPU_GHz
while (__rdtsc() < end) {
_mm_pause(); // 减少功耗并避免过度抢占
}
QueryPerformanceCounter适合校准但不适合实时忙等
QueryPerformanceCounter（QPC）精度可达~10–100ns，但它本质是查询，不是阻塞；若用于忙等，会因频繁系统调用（尤其未启用QPC硬件计数器时）引入抖动。更合理做法是：
立即学习“C++免费学习笔记（深入）”；
- 启动时用
QueryPerformanceFrequency获取真实频率，换算出1微秒对应多少计数 - 仅用它校准
RDTSC一次，之后全走RDTSC忙等 - 避免在循环内反复调用
QueryPerformanceCounter——每次调用开销远超1微秒
Linux下clock_nanosleep仍达不到1μs
clock_nanosleep(CLOCK_MONOTONIC, TIMER_ABSTIME, &ts, nullptr)理论上支持纳秒，但实际最小分辨率受HZ和调度器影响，主流内核（5.x+）通常最低只能保证2–10微秒精度；硬实时补丁（PREEMPT_RT）可改善，但普通发行版不带。真要1微秒，仍得用RDTSC或__rdtscp忙等，且需：
- 绑定到单个CPU核心（
sched_setaffinity）防止迁移 - 关闭该核的频率调节（
echo performance > /sys/devices/system/cpu/cpuX/cpufreq/scaling_governor） - 禁用中断（需root +
local_irq_disable()）——仅限内核模块，用户态不可行
用户态能做的极限，就是靠RDTSC忙等+CPU绑定+频率锁定，再加循环展开和寄存器变量优化。误差通常能压到±50ns以内，但“精确1微秒”本身是个伪命题——CPU主频有偏差、缓存命中率波动、TLB miss都会扰动，实际工程中应按“≤1.5μs”设计容忍窗口。
