time.timer在万级并发、毫秒精度场景下因单goroutine驱动、红黑树常数大、stop导致过期timer堆积及gc压力线性增长而成为瓶颈；自研二叉堆可压低常数、支持批量过期扫描、提升缓存局部性。
为什么不用 time.Timer 而要自己实现二叉堆定时器
当并发任务数上万、定时精度要求毫秒级、且大量定时器集中创建/停止时，time.Timer 的底层 timerProc 单 goroutine 驱动 + 红黑树管理会成为瓶颈：插入/删除平均 O(log n)，但常数大；频繁 Stop() 产生大量待清理的已过期但未触发的 timer；GC 压力随 timer 数量线性增长。二叉堆（小顶堆）在定时器场景下能压低常数、支持批量过期扫描、内存局部性更好。
如何用 slice 实现最小堆并保证定时器语义
Go 没有内置堆容器，但 container/heap 可以基于 []*Timer 构建。关键不是“堆结构”，而是“堆操作必须和定时器状态严格同步”——比如一个 Timer 被 Stop() 后，它仍可能在堆中，不能简单从 slice 中删掉（会破坏堆序）。正确做法是：
- 每个
*Timer持有heapIndex int字段，记录其在堆 slice 中的当前下标 -
Push()时调用heap.Push(h, t)，内部自动更新t.heapIndex -
Stop()不真正删除，只设t.stopped = true，并在Pop()或Fix()时跳过已停止项 - 每次
heap.Fix(h, t.heapIndex)必须在t.nextTime更新后立即调用，否则堆序失效
怎么处理时间推进与过期扫描的竞态
典型错误是让一个 goroutine 死循环 time.Sleep(1 * time.Millisecond) 然后扫堆——这既不准又浪费 CPU。更合理的是用 runtime_timer 底层思想：每次取堆顶 nextTime，time.Until(nextTime) 睡眠，醒来后批量弹出所有 ≤ now 的定时器。但要注意：
- 睡眠前必须加锁检查堆是否为空，避免唤醒时堆已被清空
- 弹出过期 timer 时需用
atomic.LoadPointer判断t.fn是否非 nil（防止Stop()和触发同时发生） - 不要在堆扫描 goroutine 中直接执行用户回调，应发到 worker channel，否则阻塞整个调度
- 若系统时间被大幅回拨（如 NTP 校正），堆顶时间可能“未来变过去”，此时应重置堆：把所有
nextTime 的 timer 强制标记为过期
为什么 heap.Interface 的 Less 方法不能只比 nextTime
单纯按 t.nextTime.Before(other.nextTime) 排序，在高频创建相同到期时间的定时器时，会导致堆内顺序不稳定，进而使 heap.Remove() 失效（因为无法准确定位下标）。必须引入稳定排序因子：
func (h TimersHeap) Less(i, j int) bool {
if h[i].nextTime.Equal(h[j].nextTime) {
return h[i].id <p>不加 <code>id</code> 或其他单调递增字段，<code>heap.Remove()</code> 可能删错对象，尤其在测试中用 <code>time.Now().Add(0)</code> 批量插入时极易复现。</p><p>堆定时器真正的复杂点不在结构本身，而在「停止」和「重置」这两个操作与堆索引、用户回调、系统时间三者之间的状态耦合——漏掉任意一环，都会出现定时器静默丢失或重复触发。</p>
