<p>单次定时器应使用std::chrono::steady_clock::now()记录起点，循环中用sleep_until(start + n * interval)确保精度；停止需atomic标志+超时等待；避免std::async因调度不可控；Windows下注意电源策略导致的精度下降。</p>
用 std::chrono + std::thread 实现单次定时器
核心就是让线程休眠到指定时间点再执行回调，不是轮询也不是信号。关键在别把 std::this_thread::sleep_until 和 sleep_for 搞混——前者更准，尤其跨系统时。
常见错误是直接 sleep_for(1s) 后调用函数，结果发现“定时”不准：如果回调函数本身耗时 200ms，那下一次实际间隔就是 1.2s。真正靠谱的做法是基于起始时间点计算下次唤醒时刻。
- 用
auto start = std::chrono::steady_clock::now()记录起点 - 每次循环里算
start + n * interval，再传给sleep_until - 回调必须在
sleep_until返回后立即执行，不能放在循环条件里延迟判断 - 注意
steady_clock才保证单调，system_clock可能因系统时间调整跳变
如何安全停止正在运行的定时器线程
裸用 std::thread::join() 会卡死：线程可能还在 sleep_until 中，根本没机会检查退出标志。必须配合 std::atomic<bool></bool> + 超时等待。
典型翻车场景是把 running 改成 false 后直接 join()，结果主线程永远等不到子线程结束。根本原因是 sleep_until 不响应中断，只能靠“提前唤醒+重试”来让线程有机会读取标志位。
立即学习“C++免费学习笔记（深入）”；
- 声明
std::atomic<bool> running{true}</bool>作为退出开关 - 在循环里用
sleep_until的返回值判断是否超时，而不是依赖异常 - 每次循环开头检查
if (!running) break; - 停止时先设
running = false，再调用thread.join()
std::thread 定时器和 std::async 的性能差异在哪
不用 std::async 是因为它的 launch policy 不可控：std::async(std::launch::deferred) 会延迟到 get() 才执行，完全失去定时意义；而 std::launch::async 虽然开新线程，但无法复用、没法优雅停止，还容易引发资源泄漏。
真实项目里，一个后台服务要同时跑多个定时任务（比如每 5s 心跳、每 30s 刷缓存），用一堆 std::async 就是给自己埋坑：线程数不可控、生命周期混乱、调试时连谁在 sleep 都找不到。
-
std::thread显式管理，可命名、可join/detach、可加日志定位 - 多个定时任务建议共用一个线程 + 优先队列（按触发时间排序），避免线程爆炸
-
std::async适合“一次性异步计算”，不是“周期性调度” - 别为了省几行代码用
std::async替代std::thread，调度逻辑一复杂就失控
Windows 下 std::chrono::steady_clock 的精度陷阱
在 Windows 上，默认 steady_clock 底层用的是 QueryPerformanceCounter，理论精度高，但实际受电源策略影响：笔记本合盖或切电池模式后，计时器频率可能被系统降频，导致 sleep_until 延迟比预期多出几十毫秒甚至上百毫秒。
这不是 bug，是 Windows 电源管理的设计选择。你测的时候一切正常，上线后客户反馈“定时器越来越慢”，大概率是这个原因。
- 开发期用
std::chrono::high_resolution_clock看最大可能精度（但不推荐用于定时逻辑） - 生产环境若对精度敏感（如音视频同步），得监听
SetThreadExecutionState防止系统进入低功耗状态 - 不要假设
steady_clock::now()每次调用都比上次大 1ms——它只保证单调，不保证步进均匀 - 测试必须覆盖不同电源模式，光跑在插电的台式机上没用
事情说清了就结束。定时器看着简单，但时间精度、线程安全、跨平台行为这三块最容易出隐蔽问题，尤其当逻辑从单次延时变成周期调度后，差 10ms 都可能滚成秒级偏差。
