std::condition_variable 配合 std::chrono 做定时任务易卡死，因 wait_until 仅保证“不早于”指定时间返回，且未检查唤醒原因、锁内耗时、误用 wait_for、未重校时间等均会导致任务遗漏；应使用 steady_clock + wait_until，每次唤醒后用 clock.now() 重判是否就绪，并配合原子停止标志、notify_all 和安全清理确保线程退出。
为什么 std::condition_variable 配合 std::chrono 做定时任务容易卡死
因为 wait_until 不保证唤醒后立刻执行，它只保证「不早于」指定时间返回；如果系统负载高、线程调度延迟，或你没检查唤醒原因（是超时？还是被 notify_one 打断？），就可能跳过本该触发的任务。
实操建议：
- 每次从
wait_until返回后，必须用clock.now()重算是否已到执行点，不能只信返回值 - 避免在条件变量等待前加锁后长时间持有——比如在锁内做耗时计算，会阻塞其他线程插入新任务
- 不要用
wait_for替代wait_until：相对时间无法应对系统时钟跳变（如 NTP 校正），steady_clock+wait_until才可靠 - 唤醒后若发现还没到执行时间，应继续
wait_until，而不是sleep或轮询
如何让定时任务池支持 O(1) 插入 + 近似 O(log n) 触发
核心不是堆，而是「分层时间轮（hierarchical timing wheel）」的简化版：按毫秒/秒/分钟三级桶管理任务，插入是哈希定位，触发只需检查当前桶。但 C++ 标准库没现成实现，所以多数人退而求其次用 std::priority_queue + std::chrono::time_point —— 它够用，但要注意比较器写法。
实操建议：
- 优先队列的比较器必须严格弱序，且不能捕获外部时钟状态；推荐用
operator 直接比 <code>time_point，别自己算差值 - 插入新任务时，若新时间早于当前队首，需通知条件变量（
notify_one），否则等待线程可能错过更近的截止时间 - 不要在触发逻辑里直接
pop所有到期任务：批量 pop 可能导致单次处理过久，应限制每次最多执行 16 个，剩余额外任务留到下次循环 - 任务回调函数必须是
noexcept或妥善捕获异常，否则未处理异常会终止整个工作线程
std::thread 工作线程退出时，怎么确保所有 pending 任务被清理
常见错误是线程析构前没清空队列，或调用 join 前没设停止标志，导致 wait_until 永远等下去。更糟的是，用 detach 后程序退出时任务还在后台跑，访问已销毁对象。
实操建议：
- 定义原子停止标志
std::atomic_bool stop_{false}，所有等待前先检查它；检查位置必须在锁外（避免死锁），但判断为 true 后要再进锁取剩余任务 - 退出前调用
cv.notify_all()，让等待线程有机会醒来并检查stop_ - 清理 pending 任务时，不要直接执行它们（对象可能已析构），而是记录日志或调用用户提供的 on_cancel 回调
- 线程对象应在任务池析构函数末尾才
join()，顺序不能反——否则可能 join 一个已 detach 的线程，引发未定义行为
源码里最容易被忽略的三个细节
一是 std::priority_queue 的底层容器默认是 std::vector，但如果你用自定义分配器，记得给它传 std::less<task></task> 显式模板参数，否则编译失败；二是 time_point 类型混用——比如把 system_clock::now() 和 steady_clock::time_point 直接比较，会编译不过；三是条件变量 wait_until 的超时时间必须是 steady_clock::time_point，哪怕你用 system_clock 计算，也得先转换过去。
这些点不报错，但一运行就行为诡异，查起来特别费时间。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
