std::chrono::steady_clock 是唯一靠谱的选择，因其单调递增且不受系统时间调整影响；用 system_clock 或 time(nullptr) 会导致任务重复或跳过；应配合 sleep_until 和绝对时间点调度，避免误差累积。
为什么 std::chrono::steady_clock 是唯一靠谱的选择
因为只有 std::chrono::steady_clock 保证单调递增且不受系统时间调整影响。用 system_clock 做调度，一旦用户手动改时间或 NTP 同步回拨，任务就可能重复执行或永久跳过。
常见错误是直接用 std::time(nullptr) 或 std::chrono::system_clock::now() 计算下次触发时间——这在跨时区、夏令时切换或系统时间被修正时完全不可靠。
-
steady_clock的time_point只能用于测量间隔，不能转成“年月日”，但任务调度恰恰只需要“再过 X 秒” - Windows 下它底层映射到
QueryPerformanceCounter，Linux 下通常基于CLOCK_MONOTONIC，两者都满足秒级精度要求 - 不要用
high_resolution_clock：它只是别名，不同平台可能指向system_clock，行为不一致
如何避免 sleep 精度漂移导致任务堆积
单纯用 std::this_thread::sleep_for() 等待固定间隔，在高负载或调度密集时会累积误差。比如每秒调度一次，但每次 sleep 实际耗时 1002ms，10 分钟后就晚了 20 秒。
正确做法是每次计算「绝对目标时间点」，再用 sleep_until() 对齐：
立即学习“C++免费学习笔记（深入）”；
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
auto next = start + std::chrono::seconds(1);
while (running) {
std::this_thread::sleep_until(next);
run_task();
next += std::chrono::seconds(1); // 不依赖本次 sleep 实际耗时
}
- 必须用
sleep_until()，不是sleep_for() - 每次更新
next要基于初始时间累加，而不是用上一次的now()加间隔（否则误差传递） - 如果任务执行超时（比如耗时 >1s），
next += ...仍按计划节奏推进，不会“追赶”，避免雪崩
多任务共存时怎么防止线程竞争和内存泄漏
一个线程一个任务太重，多个任务共享线程又容易互相阻塞。核心是把「调度逻辑」和「执行逻辑」彻底分离。
推荐用最小可行结构：一个调度线程维护有序队列（按下次触发时间排序），用 std::priority_queue 存 std::pair<time_point, task_id>；任务实际执行交给独立线程池。
- 调度线程只做两件事：pop 最近任务、
sleep_until、push 回队列（周期性任务） - 任务函数必须是无状态的
std::function<void()>，避免捕获外部变量导致悬挂引用 - 删除任务时不能直接从
priority_queue中移除——它不支持随机删除。改用std::set<std::pair<time_point, task_id>>，配合erase()和begin()
秒级精度下要不要考虑闰秒和系统时钟跳变
不用。闰秒只影响 system_clock，而你全程用的是 steady_clock，它根本不感知 UTC 或闰秒。系统时钟跳变（如 NTP 调整）也完全不影响它。
真正要检查的是硬件时钟漂移：普通 PC 的 steady_clock 每天误差约 ±10–50ms，对秒级任务足够。如果部署在嵌入式设备或需要长期稳定运行，得加校准机制——比如每小时用 system_clock 检查一次 steady_clock 的 drift，但仅作监控，不用于调度逻辑。
最容易被忽略的是：任务回调里调用了阻塞 I/O 或锁竞争严重，表面看调度准时，实际执行被卡住。秒级精度只管「什么时候开始执行」，不管「什么时候执行完」。
