Go ticker 不 Stop 会造成什么资源问题

如果你在 Go 1.23 或更高版本里忘了调用 Ticker.Stop，先别急着把它判定为“ticker 内存泄漏”。官方 time 文档已经说明：当 ticker 不再被引用时，垃圾回收器可以回收它，即使没有调用 Stop。真正容易留下资源问题的情况，是后台 goroutine 还握着 ticker.C，或者 ticker 被放在长期存活的结构体、全局变量里，导致定时工作和业务回调仍然继续。

所以排查要分两条线：Stop 负责关闭定时器的发送，done 或上下文负责让消费 goroutine 返回。只做其中一件，生命周期都可能没有闭合。

不 Stop 先看哪种资源还被持有

把问题拆成三个对象会更容易判断：ticker 本身、它暴露的 C 通道，以及读取通道的 goroutine。它们不是同一个生命周期。

Stop 之后不会关闭 C 通道。这不是遗漏，而是标准库刻意保留的语义：关闭通道可能让并发读取方把“没有新 tick”误判成零值事件，也会影响后续 Reset。因此不要用“等通道关闭”作为 ticker 的退出协议。

循环里真正危险的是没有退出入口

下面这种写法的问题不只是漏写 Stop：

func startPolling() {
	ticker := time.NewTicker(time.Minute)
	go func() {
		for range ticker.C {
			refreshCache()
		}
	}()
}

调用 startPolling 后，创建者没有保存停止函数，goroutine 也没有等待上下文。只要它还在运行，ticker.C 就有消费者；即使某个版本的 GC 能回收没有引用的 ticker，也不能替你结束这个 goroutine，更不能取消 refreshCache 已经启动的业务动作。

这类代码常见于 HTTP 服务启动钩子、重载配置和测试用例。每调用一次就再创建一条长期循环，表面上像“偶尔多执行一次”，实际是轮询任务的所有权没有落到可管理的对象上。

用 done 和 Stop 把轮询循环关完整

一个小而完整的写法，是让创建者同时拥有关闭信号和 ticker 的释放责任：

func runPolling(done 

这里有两个互补动作：收到 done 后，return 让 goroutine 结束；函数离开时，defer 执行 Stop。如果 processBatch 本身会阻塞，仍需把 done 或 context.Context 继续传进去，否则外层循环能退出，业务调用却可能卡住。

如果你只想获得一个永不主动停止的 channel，time.Tick 是便利封装；但需要控制生命周期的后台任务，更适合保留 *time.Ticker，因为它能表达“谁负责停止”。

修复后用三项检查确认没有假恢复

不要只看代码里出现了 defer ticker.Stop()。修复后可以按下面的清单复查：

1. 重复启动入口：确认服务重载、测试 setup 或请求处理器不会反复创建同一类轮询 goroutine。
2. 退出信号：触发关闭时，done 或 context 确实能到达 select，而不是只设置了一个没人读取的标志位。
3. 业务回调：停止后不应再看到新的轮询回调；如果回调可能并发执行，要把“循环退出”和“当前回调完成”分开记录。

排查时可用 goroutine profile 或测试里的计数器观察趋势，但不要把 goroutine 数量一次升高就直接归因给 ticker。先确认是否有重复启动，再确认旧 goroutine 是否收到退出信号，最后才看 ticker 是否仍被长生命周期对象引用。

常见问题

Go 1.23 以后还要不要写 ticker.Stop？

要。它不再是“为了让 GC 回收 ticker”这一项硬性要求，但仍然是表达业务停止、减少无意义 tick 和收束资源所有权的清晰写法。

Ticker.Stop 会关闭 ticker.C 吗？

不会。停止后不再发送 tick，消费 goroutine 仍需要通过 done、context 或其他协议返回。

time.Tick 和 time.NewTicker 怎么选？

固定运行且不需要主动停止时可以用 time.Tick；需要取消、重置或由结构体管理生命周期时使用 time.NewTicker 并保存指针。

只补 Stop 就能解决 goroutine 泄漏吗？

不能。必须同时找到 goroutine 的退出入口；如果它在等待 ticker.C，停止 ticker 也不会自动关闭通道。