Go time.Timer Stop 返回 false 时还要不要排空 channel

很多 Go 代码会这样复用定时器：先调用 t.Stop()，如果返回 false 就从 t.C 取一次，再调用 Reset。这段写法并非永远错误，但它属于 Go 1.23 之前的 channel 语义。若模块使用 Go 1.23 或更高版本，time.NewTimer 默认使用同步 channel，Stop 返回后不会再让接收方看到旧时间值；此时盲目执行阻塞式排空，反而可能把程序卡住。

Stop 的返回值到底说明了什么

Stop 的布尔值描述的是调用时的 Timer 生命周期：返回 true 表示这次调用阻止了尚未触发的定时器；返回 false 表示它已经过期，或者此前已经停止。它不是“channel 当前一定有值”的探针。

真正影响是否排空的是 channel 语义和接收方约束。Go 1.23 以前，NewTimer 的 channel 是容量为 1 的异步 channel，旧时间值可能在 Stop 或 Reset 返回后仍被接收。Go 1.23 起，默认 channel 为同步 channel，Stop 返回后，新的接收不会观察到停止前的旧值。

旧版本为什么需要排空 channel

如果代码需要兼容 Go 1.22 及更早版本，并且同一个 Timer 的 channel 没有被其他 goroutine 并发接收，可以采用旧文档中的约束式写法：

func reuseLegacy(t *time.Timer, d time.Duration) {
    // Stop 返回 false 时，旧异步 channel 里可能已经留下本轮的时间值。
    if !t.Stop() {
        

这里的前提不能省略：不能同时有另一个 goroutine 从 t.C 接收，也不能把这段代码用于 AfterFunc。如果 Timer 可能已经被别处 Stop，或者接收职责不清楚，阻塞式读取可能一直等不到值。

Go 1.23+ 应该怎么复用 Timer

面向 Go 1.23 及更高版本时，重点是让一个控制方拥有 Timer 的状态，而不是看到 false 就执行旧式 drain。可以把停止和重置放在同一段生命周期管理中：

func reuseModern(t *time.Timer, d time.Duration) {
    // 这里不把 false 当成“必须从 t.C 读取”的信号。
    t.Stop()
    // Go 1.23+ 的同步 timer channel 不会让接收方看到旧值。
    t.Reset(d)
}

如果 Timer 只由当前 goroutine 管理，也可以直接围绕 Reset 组织新的周期；不要为了迁就旧模板再写一个可能永久阻塞的 。另外，Go 1.23 的新语义只有在主模块的 go.mod 声明 go 1.23 或更高版本时默认启用。

仍要留意 GODEBUG=asynctimerchan=1：它会恢复旧的异步 channel 行为。若部署环境显式设置了这个开关，代码就应按旧语义重新审视 Stop、排空和 Reset 的组合。

几个容易把结论用错的边界

尤其不要用 len(t.C) 判断是否需要排空。Go 1.23 后 timer channel 的容量和长度始终为 0，而且并发接收会让这种判断本来就不可靠；如果确有旧语义兼容需求，应围绕明确的 Timer 所有权设计，而不是临时窥探 channel。

常见问题

Stop 返回 false 是否代表一定已经收到超时值？

不是。它只表示 Timer 已经过期或已经停止，值是否被接收还要看 channel 语义和接收方。

Go 1.23 还能保留旧的 Stop 加 drain 模板吗？

不建议无条件保留。默认同步语义下，阻塞排空可能没有值可读；只有明确启用旧语义兼容时才按旧规则处理。

Reset 前一定要先 Stop 吗？

旧语义下应先 Stop 并按条件排空；Go 1.23+ 已强化 Reset 的旧值隔离保证，但仍应让同一个控制方管理 Timer，避免并发调用造成生命周期混乱。

判断这类问题时，先确认 Go 主模块版本和 GODEBUG，再确认 Timer 是否只有一个接收者。版本、语义和所有权三项都明确后，才决定是否需要 drain。