time.Ticker 停止后释放后台任务的清理清单

在 Go 的后台轮询、定时刷新和心跳任务里，time.Ticker.Stop 只负责停止后续 tick，不负责终止正在运行的 goroutine，也不会关闭 ticker.C。真正完整的清理，要把“停止时间源、通知任务退出、等待任务结束、释放任务内部资源”放在同一条生命周期里。

我更倾向于把清理责任写成一张小清单：创建 ticker 的函数拥有它的停止责任；启动后台任务的函数拥有退出通知和等待责任；任务内部创建的文件、请求或子 goroutine，则由任务自己释放。这样即使某次 tick 正在处理，也不会把 Stop 误当成“后台工作已经结束”。

先确认 Stop 的边界

官方文档对 Ticker.Stop 的定义很明确：调用后不再发送新的 tick，但 ticker channel 不会被关闭。这样设计是为了避免并发读取者收到一个错误的“结束值”，也允许之后调用 Reset。因此，下面这种写法只能停止时间源，不能保证 runReport 已经返回：

ticker := time.NewTicker(time.Minute)
defer ticker.Stop() // 只回收当前函数拥有的 ticker，不负责停止外部 goroutine

for range ticker.C {
    // 这里的工作可能阻塞很久；Stop 不会强行中断这段工作。
    runReport()
}

从 Go 1.23 开始，垃圾回收器可以回收已经不可达的 ticker，所以 Stop 不再只是为了帮助 GC；但只要任务仍然需要提前停止，显式调用 Stop 仍然是清晰的生命周期信号。工程代码不能因为 GC 能回收，就省掉任务退出协议。

让后台任务同时收到退出信号

定时任务通常有两个独立的停止条件：ticker 不再产生新的触发，以及当前 goroutine 愿意结束。用 context.WithCancel 传递退出意图，再用 sync.WaitGroup 等待收尾，可以把两件事写在一个可重复的关闭函数中。

type Poller struct {
    cancel context.CancelFunc
    done   chan struct{}
    once   sync.Once
}

func StartPoller(parent context.Context, interval time.Duration) *Poller {
    ctx, cancel := context.WithCancel(parent)
    p := &Poller{cancel: cancel, done: make(chan struct{})}

    go func() {
        defer close(p.done) // 无论哪条退出路径，都向关闭方报告任务已结束
        ticker := time.NewTicker(interval)
        defer ticker.Stop() // ticker 由这个 goroutine 创建，也由它负责停止

        for {
            select {
            case 

这里的顺序很重要：cancel 只发出信号， 才代表后台函数已经退出。若 pollOnce 会调用不可取消的阻塞 API，仍需要给它增加超时、关闭底层连接或改用支持 context 的版本，否则等待本身可能一直卡住。

按资源所有权安排清理动作

把所有清理都堆到调用方，往往会漏掉任务内部资源；把所有清理都放到后台函数，又可能让调用方无法知道何时安全退出。可以按所有权分三层处理：

三种写法怎么选

如果 ticker 只在当前函数内短暂使用，创建后立刻 defer ticker.Stop() 最简单；如果循环要被外部提前结束，就用显式的关闭方法，把停止信号和等待动作放在一起；如果任务由服务管理器统一托管，则把所有 worker 的退出信号集中到父 context，并在关闭阶段统一等待。

不要在接收端等待 ticker.C 被关闭来判断结束，因为 Stop 不会 close 这个 channel。也不要在多个 goroutine 中随意调用 Reset，除非已经定义好谁拥有 ticker 以及谁负责同步状态。

结论：停止时间源只是清理的第一步

time.Ticker 的清理清单可以压缩成四问：ticker 是否由明确的 owner 创建？停止后后台 goroutine 是否收到退出信号？关闭函数是否等待任务完成？任务内部的请求、文件和子 goroutine 是否各自释放？只回答第一问，通常还不够。

相关问题

Stop 之后能从 ticker.C 读取到关闭信号吗？

不能把它当作关闭信号。Stop 不会关闭 C，应使用 context、done channel 或其它明确的完成通知。

Go 1.23 以后还需要调用 Stop 吗？

如果只是担心不可达 ticker 的 GC 回收，官方说明已经不再需要；但业务仍需要提前停止时，调用 Stop 能表达生命周期边界，也能让后台循环停止等待新的 tick。

为什么调用 Stop 后程序仍然有 goroutine？

因为 Stop 不会终止 goroutine，也不会取消 goroutine 正在执行的工作。需要额外的取消信号，并在关闭路径中等待任务完成。