std::this_thread::sleep_for虽跨平台，但受os调度粒度限制，windows默认10–15ms、linux通常1–10ms，导致sleep_for(1ms)实际延时远超预期；需结合忙等补偿（小延时纯忙等，大延时混合忙等+sleep）并运行时校准循环次数，才能逼近目标毫秒精度。
为什么不能直接用 std::this_thread::sleep_for
它确实跨平台，但实际精度远低于毫秒：Windows 上默认调度器粒度是 10–15ms，Linux（尤其非实时内核）也常卡在 1–10ms 区间。你调 sleep_for(std::chrono::milliseconds(1))，大概率停住 10ms 以上，甚至被调度器打断后延更久。这不是 bug，是 OS 调度策略决定的。
真正需要「尽可能接近」指定毫秒数的延时（比如做简易帧同步、轮询防抖），得绕过纯 sleep，结合忙等 + 睡眠混合策略。
如何写一个带忙等补偿的跨平台毫秒延时封装
核心思路：对小延时（比如 ≤ 2ms）用 std::chrono::high_resolution_clock + 空循环忙等；对大延时，先忙等掉一部分（如前 0.5ms），再用 std::this_thread::sleep_for 剩余时间，减少调度误差。
- 忙等部分必须用
volatile或std::atomic_signal_fence防止被编译器优化掉 - 忙等循环次数不能硬编码——不同 CPU 主频差异太大，需运行时校准（首次调用测 1ms 实际循环次数）
- 校准值缓存到静态变量，避免每次重算；但要注意多线程首次竞争，加
std::call_once保护 - 总延时 = 忙等部分 + sleep 部分，sleep 部分至少保留 1ms，否则
sleep_for可能直接返回（底层实现对极短时间常忽略）
示例关键片段：
static std::once_flag calibrate_flag;
static long long cycles_per_ms = 0;
<p>void calibrate() {
auto start = std::chrono::high_resolution_clock::now();
volatile int dummy = 0;
for (long long i = 0; i (end - start).count();
cycles_per_ms = (1000 * 100000) / (us ? us : 1);
}</p><p>void ms_sleep(int ms) {
if (ms </p><pre class="brush:php;toolbar:false;">auto start = std::chrono::high_resolution_clock::now();
const int busy_ms = std::min(ms, 2); // 忙等最多 2ms
const int sleep_ms = ms - busy_ms;
// 忙等 busy_ms
long long cycles = busy_ms * cycles_per_ms;
volatile int dummy = 0;
for (long long i = 0; i 0) {
std::this_thread::sleep_for(std::chrono::milliseconds(sleep_ms));
}}
Windows 下用 QueryPerformanceCounter 能提高精度吗
可以，但没必要单独封装——std::chrono::high_resolution_clock 在 Windows 上底层就是 QueryPerformanceCounter，只要编译器支持 C++11 就已启用。别自己手撸 QueryPerformanceCounter + QueryPerformanceFrequency，徒增平台判断和类型转换风险。
真正要注意的是：high_resolution_clock 在某些旧版 MinGW 或嵌入式 STL 实现里可能退化为 system_clock（秒级精度）。如果遇到这种情况，先检查 std::chrono::high_resolution_clock::is_steady 返回 true 吗，false 就得换方案或升级工具链。
Linux 上 nanosleep 比 sleep_for 更准？
不明显。glibc 的 std::this_thread::sleep_for 底层就是调 nanosleep，差别只在 C++ 封装层开销（可忽略）。但如果你手动用 nanosleep，要自己处理 errno == EINTR 重试，而 sleep_for 已帮你做了。
想进一步压低延迟，唯一有效路径是：改进程调度策略（sudo chrt -f 99 ./your_app）、关掉 CPU 频率调节（echo performance | sudo tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor），但这已超出函数封装范畴，属于部署调优。
校准用的忙等循环在不同 CPU 上表现差异很大——ARM 和 x86 指令吞吐不同，超线程开启与否也影响结果。所以别把校准值写死，哪怕同型号机器，也建议每次进程启动时重新跑一次校准（或提供强制重校准接口）。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
