用std::thread+sleep_for可实现跨平台定时器：启分离线程循环等待并执行回调，用steady_clock控制精度，避免system_clock跳变；需atomic标志或condition_variable安全停止，注意单位指定和对象生命周期。
用 std::thread + std::this_thread::sleep_for 实现最简跨平台定时器
不需要第三方库，C++11 起就能跑通所有主流平台（Windows/macOS/Linux）。核心思路是：启动一个分离线程，循环等待+执行回调，靠 std::chrono 控制精度。
常见错误是直接在主线程里用 sleep_for 阻塞——这会让整个程序卡住，不是“定时器”，只是“延时暂停”。真正定时器必须异步。
- 用
std::thread启动后台线程，立即调用detach()或管理其生命周期（推荐用std::unique_ptr持有） - 每次循环开头计算下次触发时间点（
std::chrono::steady_clock::now()），再用sleep_for补足间隔，避免累积误差 -
回调函数需捕获外部变量时，注意生命周期——若定时器比捕获对象活得久，会崩溃。建议传值或用
std::shared_ptr - Windows 下
sleep_for最小分辨率约 15ms，Linux/macOS 通常更准；要求亚毫秒级请换epoll/kqueue或专用库
如何安全停止定时器（避免资源泄漏和竞态）
裸线程 + while(running) 是常见写法，但 running 变量必须是 std::atomic，否则可能被编译器优化掉读取，导致线程永不退出。
更可靠的做法是用 std::condition_variable 配合 std::mutex，让停止请求能立刻唤醒休眠中的线程，而不是等下一次循环才检查标志位。
立即学习“C++免费学习笔记（深入）”；
- 停止时先置标志，再调用
notify_one()打断wait_for - 不要在线程函数里直接
join()自己——会导致死锁；应在控制对象的析构中join() - 若使用
detach()，确保回调不访问已销毁对象，否则是未定义行为，调试极难定位
std::chrono 时间单位选错导致定时不准
写 sleep_for(1000) 是错的——它睡的是 1000 个 std::chrono::system_clock::period（通常是纳秒），不是毫秒。必须显式指定单位。
正确写法只有两种：
std::this_thread::sleep_for(std::chrono::milliseconds(1000))-
std::this_thread::sleep_for(1s)（C++14 起支持字面量，需包含
混用 system_clock 和 steady_clock 也会出问题：system_clock 可能因系统时间调整跳变，定时器周期忽长忽短；必须用 steady_clock 做间隔计算。
要不要用 boost::asio::steady_timer？
如果项目已依赖 Boost，且需要高并发、大量定时器（如每秒上千次）、或与网络 I/O 统一调度，boost::asio::steady_timer 是更稳的选择。它底层复用 epoll/kqueue/IOCP，无额外线程开销。
但纯做简单轮询任务（比如每 5 秒查一次配置文件），引入 Boost 反而增加构建复杂度和二进制体积。标准库方案足够用，也更容易审计和移植。
真正容易被忽略的是信号安全：在 SIGALRM 或 setitimer 方案里，回调函数不能调用非异步信号安全函数（如 malloc、std::cout）；而线程方案没这限制，但要自己管好数据竞争。
