Go time.Ticker 用在长循环里怎么保证退出时停止

Go 的 time.Ticker 适合给长循环提供周期事件，但“停止 ticker”和“结束循环”是两个动作。可靠写法是让循环同时监听 ticker.C 与退出信号，在拥有 ticker 的函数里执行 defer ticker.Stop()，再用完成通知告诉调用方 goroutine 已经退出。这样即使循环当前没有等到下一次 tick，也能及时收尾。

只要长循环仍然由当前函数负责，就由当前函数创建并停止 ticker；退出条件放进同一个 select，复用周期用 Reset，不能用关闭 ticker.C 来表示结束。

一、先把退出信号和 ticker 放在同一层

最容易出问题的代码是只写 for range ticker.C。这个循环只能等时间事件，业务停止时没有第二个出口。把退出通道和 ticker.C 放在同一个 select 中，停止条件才与工作事件处在同一控制边界。

func runLoop(done 

NewTicker 的周期必须大于零，否则会 panic。示例中的 done 只负责表达退出意图，真正的清理由函数返回后的 defer ticker.Stop() 完成；不要把 done 当作 ticker 的替代品。

二、退出路径里调用 Stop 并等待循环结束

如果 runLoop 在独立 goroutine 中运行，调用方发送停止信号后还需要知道它何时真正退出。可以增加一个只关闭一次的 finished 通知。Stop 不关闭 ticker.C，这是刻意设计，用来避免接收方把 channel 关闭误判成一次业务 tick。

func startWorker(ctx context.Context, interval time.Duration) 

调用方可以先取消 ctx，再等待 finished。若还有连接、文件或 worker 池要释放，放在收到 finished 之后更稳妥，因为这时循环已经不可能再次使用这些资源。

三、复用长生命周期 ticker 时用 Reset

同一个 worker 只是临时改变周期时，不必重新创建 ticker 并覆盖旧引用。ticker.Reset(interval) 会停止当前计时并以新周期重新计时，下一次 tick 会在新周期之后到达。Reset 的参数同样必须大于零，而且不要让多个 goroutine 同时修改同一个 ticker。

func applyInterval(ticker *time.Ticker, interval time.Duration) {
	// 由 ticker 的唯一 owner 串行调整周期，避免并发 Reset。
	if interval 

如果新周期来自配置热更新，要先把配置更新消息交给负责循环的 goroutine，再由它调用 Reset。若 ticker 的所有权已经转移或循环准备退出，直接走 Stop，不要一边退出一边 Reset。

四、根据慢处理和并发场景做收尾检查

每次 tick 到来并不代表每次任务都必须执行。官方文档说明，接收方处理较慢时，ticker 会调整间隔或丢弃 tick 来追赶时间；因此 ticker 更适合“按周期触发一次检查”，不适合作为不能丢失的任务队列。必须逐次处理时，应把任务放进队列并单独确认积压。

Go 1.23 起，垃圾回收器可以回收不再可达且未停止的 ticker，但这不改变显式 Stop 的工程价值：它表达生命周期结束，也让代码审查能直接看出资源边界。尤其是长循环、测试替身和热更新 worker，不要依赖垃圾回收来代替退出协议。

常见问题

Stop 之后为什么不能从 ticker.C 收到“关闭”信号？

因为 Stop 不关闭 channel。循环应该监听自己的 done 或 context.Done()，不能通过 range 等待 ticker.C 结束。

长任务执行时收到退出信号，能立即停止 refreshCache 吗？

不能自动停止。应把 context 继续传给任务，让任务内部检查取消；否则外层循环只能在本次处理返回后退出。

可以用 time.Tick 代替 NewTicker 吗？

只需要一个无法主动调整周期的简单循环时可以，但需要显式 Stop、Reset 或等待退出确认时，应使用 NewTicker，保留 ticker 对象的所有权。

相关事实可从 Go time 包文档核对：NewTicker、Stop、Reset 的生命周期语义分别不同。最终审查只问四件事：谁创建、谁停止、谁接收、谁确认退出。