Go 的 time.Timer 和 time.Ticker 有哪些使用陷阱？

结论：三个经典陷阱：1）1.23 之前 Timer 到期后 channel 里残留的值让 Reset 语义复杂——重置前要 Stop 并视情况 drain channel，写错就出竞态（读到旧触发）；2）Ticker 不补偿慢消费者——间隔到期时若无人接收，后续触发直接丢弃（channel 容量为 1），处理慢于间隔会"跳拍"而非堆积；3）time.After 在循环里每次新建 Timer 且无法 Stop，高频循环下 Timer 堆积直到到期才释放，内存压力明显。

展开：Go 1.23 的重要修复：Timer/Ticker 改为"无缓冲同步式"语义——Stop/Reset 保证返回后 channel 不会再收到旧值，未消费的 Timer 可被 GC 回收，time.After 的堆积问题随之消失；升级前老代码的 drain 写法（select { case <-t.C: default: }）在新版本下依然正确但不再必要。实践守则：1）周期性任务用 Ticker 且 defer ticker.Stop()（不 Stop 的 Ticker 在旧版永不回收）；2）一次性超时用 Timer 变量而非 time.After（需要可取消时）；3）节奏敏感场景（限速器）用 time.Tick 的替代——rate.Limiter 或自算 next = next.Add(interval) 对齐时刻，避免漂移。易错点：select 里 <-time.After(d) 每轮重建计时器，放在 for-select 里是延迟逻辑 bug 的常见来源——应该 for 外建 Timer。

t := time.NewTimer(d)
defer t.Stop()
select {
case <-t.C:
    // 超时
case <-work:
    // t 被 Stop，旧版本需注意 drain，1.23+ 无残留
}

追问方向：运行时时间堆（四叉小顶堆）的实现、1.23 改动的兼容性讨论（GOEXPERIMENT/文档变更而非 godebug）。