std::priority_queue默认是最大堆，因使用std::less比较器，故定时器需显式指定std::greater或自定义仿函数实现最小堆，确保最早到期任务位于堆顶。
为什么 std::priority_queue 默认不是最小堆
因为 std::priority_queue 默认用 std::less<t></t> 作为比较器，底层是最大堆——顶部元素是最大值。定时器需要最快到期的（即最小到期时间）排在队首，所以必须改成最小堆。
常见错误是直接写 std::priority_queue<timertask></timertask>，结果 top() 返回最晚触发的任务，导致定时器逻辑完全颠倒。
正确做法是显式传入 std::greater<t></t>，前提是 T 支持 operator>，或者自定义比较仿函数：
struct TimerTask {
long long expire_at; // 毫秒时间戳
std::function<void()> cb;
bool operator>(const TimerTask& rhs) const { return expire_at > rhs.expire_at; }
};
// 方式1：用 std::greater（需定义 operator>）
std::priority_queue<TimerTask, std::vector<TimerTask>, std::greater<TimerTask>> heap;
// 方式2：用 lambda（C++20 起支持，但注意不能直接用于模板参数，需用 struct 包装）
// 更稳妥：用自定义仿函数对象
struct EarlierExpire {
bool operator()(const TimerTask& a, const TimerTask& b) {
return a.expire_at > b.expire_at; // 注意：这是“a 应该排在 b 后面”的逻辑，即小顶堆
}
};
std::priority_queue<TimerTask, std::vector<TimerTask>, EarlierExpire> heap;
如何安全地从堆中取出已到期任务
定时器主线程（或 IO 线程）需循环检查堆顶是否到期，但必须注意：不能只 top() 一次就跳出，因为可能多个任务在同一时刻到期；也不能无限制 pop() 直到堆空——得用当前系统时间做边界判断。
立即学习“C++免费学习笔记（深入）”；
典型误操作是：
- 用
while (!heap.empty() && heap.top().expire_at 却忘了在循环内 <code>pop()，导致死循环 - 在回调执行过程中又往堆里插入新任务，而此时正在
pop()，虽不导致崩溃，但新任务不会被本轮处理
推荐结构：
auto now = GetMonotonicMillis(); // 务必用单调时钟，不用 system_clock
while (!heap.empty() && heap.top().expire_at <= now) {
auto task = std::move(heap.top());
heap.pop();
task.cb(); // 执行回调
}
注意：task.cb() 是用户代码，可能抛异常、阻塞、甚至递归调用 add_timer() —— 这本身没问题，只要确保堆操作（push/pop）是线程安全的（见下一点）。
多线程环境下 push/pop 的线程安全怎么做
std::priority_queue 本身不是线程安全容器。如果一个线程在 push()，另一个在 pop() 或 top()，会引发未定义行为（常见表现是崩溃或数据错乱）。
不能靠“我只在单个线程里操作”来假设安全——定时器通常有两类线程：工作线程调用 add_timer()，而定时器驱动线程（比如 epoll/kqueue 循环或独立 timer thread）负责到期检查和回调。
简单有效的方案是加互斥锁，但要注意粒度：
- 不要把整个事件循环锁住（比如把
while(!heap.empty() && ...)整个包进 lock）——会严重拖慢定时器响应 - 只锁必要的临界区：
push()、top()、pop()这三个操作各自包裹std::lock_guard - 回调
task.cb()必须在锁外执行，否则用户代码阻塞会导致其他线程长期等待
示例：
std::mutex heap_mtx;
// add_timer:
{
std::lock_guard<std::mutex> lk(heap_mtx);
heap.push(std::move(task));
}
// tick loop:
while (true) {
auto now = GetMonotonicMillis();
std::vector<TimerTask> expired;
{
std::lock_guard<std::mutex> lk(heap_mtx);
while (!heap.empty() && heap.top().expire_at <= now) {
expired.push_back(std::move(heap.top()));
heap.pop();
}
} // 释放锁
for (auto& t : expired) t.cb(); // 在锁外执行
sleep_until_next_expiry(); // 如需休眠，算好下一个最近 expire_at
}
为什么不能用 std::chrono::time_point 直接当堆元素
有人尝试用 std::pair<:chrono::steady_clock::time_point std::function>></:chrono::steady_clock::time_point> 做堆元素，认为 time_point 已支持 ，省得自己写比较逻辑。但问题在于：<code>time_point 的 operator 虽可用，但它在 <code>std::priority_queue 中仍会构建最大堆，除非你主动指定 std::greater<...></...>。
更隐蔽的问题是精度与可比性：不同 clock 的 time_point 类型不同（system_clock::time_point 和 steady_clock::time_point 不可混用），且 time_point 无法直接序列化/调试打印，出问题时难排查。
建议统一转为整数时间戳（如毫秒级 long long），好处是：
- 比较开销小（整数比
time_point构造/转换快） - 跨平台一致（避免 Windows/Linux 下
steady_clock分辨率差异） - 便于日志记录和调试（直接
std::cout ）
获取方式务必用单调时钟：
// 推荐：使用 steady_clock + duration_cast
inline long long GetMonotonicMillis() {
return std::chrono::duration_cast<std::chrono::milliseconds>(
std::chrono::steady_clock::now().time_since_epoch()).count();
}
实际最难处理的不是堆本身，而是时间跳变（NTP 校正、手动改系统时间）和回调重入——这些必须在上层业务逻辑里防御，std::priority_queue 只负责按序交付。 
