std::condition_variable::wait_for() 无法毫秒级精准，因其依赖系统时钟粒度与调度延迟；windows 默认约15.6ms，linux虽支持纳秒但唤醒仍受调度影响，实测误差常达±2–8ms，且语义为“至少等待”而非精确唤醒。
为什么 std::condition_variable 等待无法做到毫秒级精准
因为 std::condition_variable::wait_for() 的底层依赖操作系统调度和时钟粒度，Windows 默认时钟分辨率约 15.6 ms（取决于 timeBeginPeriod），Linux 的 clock_nanosleep 虽支持纳秒，但实际唤醒仍受调度延迟影响。实测中，即使设为 1ms 等待，连续 100 次的误差常达 ±2–8ms —— 这不是 bug，是并发等待机制的固有特性。
关键点：wait_for 是“至少等待”，不是“精确在某时刻唤醒”。它适合节流、限频等容忍抖动的场景，不适合硬实时周期触发。
用 std::chrono + busy-wait 补偿调度延迟（适用短周期）
若定时周期在 1–20ms 且 CPU 资源可控，可在 wait_for 后加自旋校准。原理：先用 wait_for 接近目标时间，再用 std::chrono::steady_clock::now() 检查是否已超时，未到则小步忙等。
auto start = std::chrono::steady_clock::now();
auto target = start + std::chrono::milliseconds(5);
std::this_thread::sleep_for(target - start - std::chrono::microseconds(100)); // 留 100μs 余量
while (std::chrono::steady_clock::now() < target) {
// 空循环，或 _mm_pause() 降低功耗
}
- 只适用于单核或绑核场景，否则线程可能被抢占导致忙等失效
- 100μs 余量经验值：太小易过早退出，太大增加平均延迟
- Linux 下可配合
sched_setscheduler(SCHED_FIFO, ¶m)提升优先级，但需 root 权限
跨平台高精度方案：Windows 用 CreateWaitableTimer，Linux 用 timerfd_create
真正毫秒级（甚至 sub-ms）稳定触发，必须绕过用户态等待，用内核级定时器：
立即学习“C++免费学习笔记（深入）”；
Windows：CreateWaitableTimer + SetWaitableTimer 可设 dwPeriod 实现周期触发，配合 WaitForSingleObjectEx 支持可中断等待，精度可达 0.5–1ms（启用 timeBeginPeriod(1) 后）。
Linux：timerfd_create(CLOCK_MONOTONIC, TFD_NONBLOCK) 创建文件描述符定时器，用 timerfd_settime 设置 it_interval，再通过 epoll_wait 或 read() 获取到期事件，实测抖动
注意：二者 API 差异大，封装时建议用策略模式隔离，避免运行时判断 OS。
std::condition_variable 配合时间补偿的实用限频写法
多数业务场景（如网络心跳、日志批量刷盘）不需要绝对精准，只要长期频率达标即可。此时用 condition_variable 更轻量、更安全：
std::mutex mtx;
std::condition_variable cv;
std::chrono::steady_clock::time_point last_tick;
<p>void rate_limited_loop() {
last_tick = std::chrono::steady_clock::now();
while (running) {
auto now = std::chrono::steady_clock::now();
auto sleep_ms = std::chrono::duration_cast<std::chrono::milliseconds>(
last_tick + std::chrono::milliseconds(10) - now).count();
if (sleep_ms > 0) {
std::unique_lock<std::mutex> lk(mtx);
cv.wait_for(lk, std::chrono::milliseconds(sleep_ms));
}
last_tick += std::chrono::milliseconds(10); // 固定步长，防 drift 累积
do_work();
}
}
核心技巧：last_tick 用固定步长递增，而非每次基于 now() 计算——否则系统负载高时会越积越多延迟。这个写法在 99% 场景下足够稳，且无忙等开销。
容易忽略的一点：如果 do_work() 耗时超过周期（比如 12ms 的任务跑在 10ms 定时器上），必须检测并跳过本次，否则队列会雪崩。这比“精度”本身更致命。
