Go time.Ticker 如何安全停止：收尾顺序与重复 Stop 的资源边界

定时任务停不干净时，表面上像是 goroutine 泄漏，现场通常却更具体：业务已经收到退出信号，ticker.Stop() 也调用了，但最后一轮任务仍在继续，或者收尾函数被多个分支重复执行。Go 的 time.Ticker 可以安全停止，关键是把“停止产生新 tick”和“等待当前任务收尾”分成两个动作，并让退出路径只有一个负责人。

最小可靠写法是：创建后由同一协程负责 ticker.Stop()，循环同时监听 ticker.C 和退出信号；收到退出后先停止 ticker，再等待正在运行的任务完成，不能把重复 Stop 当成业务状态判断。

症状不是 Ticker 忘了 Stop 这么简单

一个每秒刷新缓存的 worker，收到 context.Done() 后仍然打印一条刷新日志，最容易让人先去找漏掉的 Stop。但如果日志来自已经开始的任务，补一行 ticker.Stop() 并不能把它从中途抹掉；真正要确认的是 tick 到达、任务启动、退出信号和任务结束之间的先后关系。

下面的示例只保留一个 worker。它把 time.NewTicker、ticker.C、ticker.Stop 和 done 放在同一条可检查的控制流里，先复现边界，再修复收尾。

按时间线还原一次错误收尾

假设刷新函数通常耗时 300 毫秒，ticker 每 1 秒触发一次。某一时刻 tick 已经从 ticker.C 取出，worker 正在执行 refresh()，这时 done 被关闭。此时有两件事同时发生：

• 退出分支可以立刻调用 ticker.Stop()，阻止后续周期继续产生。
• 当前已经进入 refresh() 的调用不会因为 Stop 自动退出，仍需让它返回或由业务上下文取消。

所以“Stop 已执行”与“worker 已结束”是两个不同的可见状态。监控若只记录前者，容易把仍在运行的尾部任务误判为泄漏。

触发条件：把退出信号放到同一个 select

最小实现如下。done 由上层关闭，worker 的所有权明确：它创建并停止 ticker，外部不再直接操作 ticker。

func runRefresh(done 

这里的 defer ticker.Stop() 是最后一道资源收尾；done 分支负责让循环不再接收新的周期。若 refresh 自身可能长时间阻塞，应把取消能力传进刷新函数，而不是期待 Stop 中断它。

根因：重复 Stop 没有业务语义

Ticker.Stop() 没有返回值，调用两次不会告诉你“第一次是谁停的”。这正是它和业务状态不同的地方：它是资源操作，不是一次可查询的状态迁移。若关闭流程有 HTTP handler、信号处理器和测试清理三个入口，最稳妥的做法不是到处补 Stop，而是让一个 owner 负责关闭，其他入口只发出退出请求。

修复动作：等待 worker 返回，再报告关闭完成

如果调用方需要一个明确的关闭结果，应保存 worker 的完成信号。下面的包装器让关闭顺序可验证：先关闭 done，再等待 workerErr，而不是把 Stop 当成完成回执。

type Refresher struct {
    done      chan struct{}
    workerErr chan error
}

func (r *Refresher) Close() error {
    close(r.done)
    return 

真实项目里要保证 Close 只由一个 owner 调用；若 API 必须允许重复关闭，可再用 sync.Once 保护关闭动作，但不要因此改变“等待 worker 返回后才算关闭完成”的判断。

防复发：三项收尾检查

1. 日志同时记录“收到退出信号”“停止 ticker”“worker 返回”，不要只打 Stop 一条日志。
2. 给 refresh 增加可取消的上下文或超时，验证它不会把 worker 永久卡在 tick 分支。
3. 测试至少覆盖空闲时关闭、refresh 执行中关闭、重复 Close，以及错误返回后的 ticker 收尾。

测试时不要依赖刚好等到一个 tick。更可靠的断言是等待 worker 完成信号，并确认关闭后没有新的刷新计数；这样测的是状态变化，不是调度时序的偶然性。

相关问题

调用 ticker.Stop() 后，ticker.C 会自动关闭吗？

不要把它当成关闭通道使用。Stop 的职责是停止 ticker，循环应通过 done 或上下文取消退出。

Stop 能取消已经执行的 refresh 吗？

不能。已经进入的函数需要自己的取消协议，例如接收 context.Context 并检查取消状态。

重复 Stop 会报错吗？

Stop 没有返回错误。要表达“只关闭一次”，应在业务层约束 owner，或用 sync.Once 保护关闭流程。

验收结论

把 ticker 看成“产生周期信号的资源”，把 worker 看成“需要等待的执行者”，收尾边界就清楚了：ticker.Stop 负责不再接收新周期，done 负责退出控制流，worker 返回才代表本轮关闭完成。三者各自有单一职责，重复 Stop 也不会再被误当成业务成功信号。