Go time.Timer复用时停止旧计时并排空通道的写法

在循环里复用 time.Timer，真正容易出错的不是 Reset 本身，而是上一轮计时已经到期、事件还没有被当前代码接收。旧版 Go 的计时器通道带一个缓冲槽，直接重置可能让下一轮读到旧时间点。

先看 go.mod，再决定是否需要排空

Go 1.23 改变了 time.NewTimer、time.After 和 time.NewTicker 使用的通道语义：计时器通道变为同步通道，Stop 或 Reset 返回后，接收方不会再看到旧配置准备的时间值。项目的 go.mod 使用 go 1.23 或更高版本时，复用代码可以直接围绕新的保证组织。

如果项目仍支持旧版本，或者测试通过 GODEBUG=asynctimerchan=1 强制旧行为，就要保留停止后排空的兼容路径。这个判断不是看当前编译器版本，而是看主模块的版本声明和运行时设置。

旧语义下的 Stop 与排空模板

旧版写法的关键是：Stop 返回 true，说明计时器在调用时仍处于活动状态；返回 false，说明它已经到期或此前已经停止。后者不等于通道一定有值，所以排空必须是非阻塞的。

// resetTimerForLegacy 在旧计时器语义下安全准备下一轮计时。
// 调用者必须保证没有其他 goroutine 同时读取 timer.C 或调用 Stop/Reset。
func resetTimerForLegacy(timer *time.Timer, d time.Duration) {
	if !timer.Stop() {
		// Stop=false 只说明计时器不再活动；C 可能为空，因此不能阻塞等待。
		select {
		case 

排空动作必须发生在同一所有者内部，并且不能与其他接收者并发。尤其不要把 无条件写成阻塞接收：当 Stop 返回 false 但值已被其他路径接走时，代码会永久卡住。

把复用权收拢到一个循环所有者

比“记住一段排空代码”更重要的是限制并发边界。下面的循环让一个 goroutine 同时负责等待、取消、停止和重置；业务处理可以放在 handleBatch 中，但不要让它另起 goroutine 读取同一个 timer.C。

// pollUntilDone 使用一个 Timer 反复等待批处理间隔，并支持外部取消。
func pollUntilDone(ctx context.Context, interval time.Duration, done 

这段示例用于说明所有权和生命周期，生产代码应根据项目的 Go 版本把重置动作封装成版本明确的 helper。不要在一次调用已经从 C 收到时间值后，再额外无条件排空；那会把下一轮尚未发生的值误当成旧值。

Go 1.23 后可以简化什么，不能简化什么

启用 Go 1.23 计时器语义时，计时器已经到期但尚未接收的场景不会在 Reset 后泄漏成旧值，旧式的“Stop 返回 false 就排空”兼容代码不再是必需条件。可以写成：

// resetTimerForGo123 适用于 go.mod 声明 Go 1.23+ 且未强制旧计时器语义的项目。
func resetTimerForGo123(timer *time.Timer, d time.Duration) {
	timer.Reset(d) // 新语义保证 Reset 返回后不会接收到旧配置的时间值。
}

但这不意味着可以并发调用 Reset，也不意味着可以关闭 timer.C。Timer 的通道仍由标准库管理，Stop 也不会关闭通道。若 CI 或线上设置了 asynctimerchan=1，代码又回到旧语义，兼容 helper 需要重新生效。

复用 Timer 前的检查清单

常见问题

Stop 返回 false 是否一定代表 C 里有值？

不是。它只表示计时器已经到期或已经停止，值可能已被接收，也可能尚未进入可接收状态，所以旧语义下应使用非阻塞接收。

Reset 前为什么不能直接无条件读取 timer.C？

因为通道可能为空，阻塞读取会把正常路径卡住；如果另一个 goroutine 已经读取过，等待也没有意义。

Go 1.23 以后还要调用 Stop 吗？

不再需要依靠 Stop 让不可达计时器及时被回收，但业务仍可用 Stop 表达退出生命周期。它不能替代单一所有者规则，也不能关闭 C。