Go time.Timer.Reset 的复用边界：停止、排空与并发读取的安全写法

日常写请求处理循环的时候，经常会碰到这类需求：等待指定时长，期间收到事件就直接往下走，超时了就执行收尾逻辑。要是每轮等待都新建一个 time.Timer，高频短循环场景下很容易产生大量冗余临时对象；直接调用 Reset 又可能把上一轮残留的到期信号和本轮等待逻辑混在一起，触发意料之外的分支。更稳妥的写法是让单个 goroutine 独占 timer.C，每次复用前先正确处理 Stop 的返回结果，清理干净通道里的残留数据。

复用 time.Timer 时，先停止旧计时器，再根据 Stop 返回值决定是否排空 timer.C，最后才调用 Reset；不要让多个 goroutine 同时读取同一个通道。

先把等待模型定下来：谁拥有 timer.C

time.Timer 有两个值得分开的对象：定时器本身，以及只读通道 timer.C。真正接收时间信号的动作发生在通道读取处。为了让复用边界可验证，下面的示例只让 waitLoop 读取 timer.C，外部 goroutine 只向 events 发送事件。

func waitLoop(ctx context.Context, events 

这里的真实调用链是 waitLoop 创建 time.NewTimer，再由 select 同时观察 events、timer.C 和 ctx.Done()。没有第二个 goroutine 偷读 timer.C，超时和取消的归属就清楚了。

Stop 返回值决定是否需要处理旧信号

当业务要在同一个循环里继续等待下一件事件时，不能只写 timer.Reset(window)。先调用 Stop，如果它返回 false，说明计时器已经停止、已经到期，或到期动作正在进行；此时要确认旧信号不会留给下一轮。

func resetTimer(timer *time.Timer, window time.Duration) {
    if !timer.Stop() {
        select {
        case 

Stop、timer.C 和 Reset 构成一个状态变化：先从运行中进入停止或已到期分支，再尝试消费已经可读的旧信号，最后回到下一轮运行状态。default 让排空动作不会永久阻塞。

把复用放进事件循环，并为每个分支写验收结果

下面的循环会在收到事件后继续等待，而不是立即销毁定时器。关键点是：事件分支先完成当前业务，再通过 resetTimer 开始新的窗口；超时和取消分支则离开循环。

func collect(ctx context.Context, events 

验收时不要只看“函数返回了”。事件到达后，got 应该增加一项且下一次超时窗口重新开始；真正超时后函数返回已收集的数据；取消后也应返回当前数据，并且 defer timer.Stop() 负责清理。

三个容易误判的边界

• 把 Stop 当成排空。Stop 不会替你读取 timer.C；它只返回计时器是否在到期前停止。
• 多个 goroutine 争抢 timer.C。 这样会让某个 goroutine 抢走本应由事件循环处理的信号，所有权应该收敛到一个读取方。
• 用 Reset 代替退出清理。 退出路径仍应调用 Stop，尤其是窗口很长而循环可能提前取消时。

相关问题

Reset 会创建一个新的定时器吗？

不会。它复用现有的 time.Timer 并设置新的到期时间；如果还需要旧计时器，就不要用 Reset 代替创建。

Stop 返回 true 就一定没有旧信号吗？

它表示计时器在到期前被停止。工程上仍应让同一个消费方负责后续状态，避免把通道读取权分散到多个 goroutine。

什么时候应该改用 time.Ticker？

当需求是固定节拍的重复通知，而不是“事件到来就重新开一个等待窗口”时，time.Ticker 的语义更直接。两者不要仅因为都能产生时间信号就混用。

小结

time.Timer.Reset 的安全复用依赖一条完整链路：单一消费方读取 timer.C，复用前处理 Stop，必要时非阻塞排空，再调用 Reset。把这条链路放进可测试的事件循环，超时、事件和取消三种结果都会有明确归属。