Go time.Ticker 怎样避免停止后继续泄漏

调用 ticker.Stop() 后，后台 goroutine 仍然存在，首先应检查接收循环有没有独立的退出条件。Stop 管的是周期源，不会关闭 ticker.C，因此它不能让 for range ticker.C 自行结束。实用配方是：调用方发出取消请求，循环监听取消并返回，循环退出时停止 ticker，再关闭一个专门的完成通知通道。

本文只处理 ticker 与消费循环的生命周期，不展开定时调度平台。官方接口说明：https://pkg.go.dev/time#Ticker.Stop；取消接口：https://pkg.go.dev/context#WithCancel。

问题卡：停止周期源，不等于关闭接收循环

一个常见误区是在外部停止 ticker，却让内部循环始终等待它的通道。这个循环并没有收到退出协议；把 Stop 换成 defer，也不会改变接收行为。defer 只有在所在函数返回时才执行，而接收循环可能根本没有返回机会。

需要分开讨论两种资源：ticker 维护周期事件，goroutine 承载接收和业务执行。按当前 time 文档，自 Go 1.23 起，垃圾回收器可以回收已无引用、即使尚未停止的 ticker，因此“不 Stop 就一定泄漏 ticker”的旧结论不应照搬。但垃圾回收不会替你终止一个仍然阻塞的 goroutine。本文标题所说的“停止后继续泄漏”，重点正是生命周期没有闭合的消费循环。

最小配方：取消请求与完成通知分开

约定两个不同方向的信号：ctx.Done() 表示“请结束”，返回的 done 表示“循环已结束”。调用方执行 cancel 后，再接收 done，才能把关闭阶段和下一阶段可靠衔接。不要把同一个通道既当停止请求，又当完成公告。

ticker 由启动函数创建，但只由循环持有并在退出处 Stop；完成通道也只由循环关闭。调用方拿到只读通道，不能擅自公告完成。这样的所有权分配，比在多个退出分支复制 Stop 和 close 更容易维护。

关键实现：defer 顺序与回调取消边界

下面完整片段先注册 defer close(done)，再注册 defer ticker.Stop()。defer 按逆序执行，所以完成通知发生在周期源停止之后。无需在每个 return 前重复写清理代码，也不能尝试关闭 ticker.C；它不是由业务代码拥有的发送通道。

回调在循环内部同步执行，避免每次 tick 都起一个无上限的独立 goroutine。但代价也很明确：如果 work 永久阻塞或忽略取消，循环无法回到 select，等待 done 的调用方也会一直等。真实数据库或网络调用应使用支持 context 的接口，并设置适合业务的超时。把 work 包进另一个 goroutine 并立刻返回，只是把退出问题转移了位置。

select 没有“取消分支永远优先”的承诺。tick 与取消同时就绪时，任一可用分支都可能被选中。调用 work 前检查 ctx.Err 可以减少额外执行机会，却不能承诺 cancel 返回后绝不会开始一次回调：检查与调用之间仍存在竞态窗口。需要严格停机边界时，应额外设计启动许可和互斥协议，不能只靠调整 case 顺序。

完整配方：可等待退出的串行周期任务

下面是独立 main 示例，代码按接口语义编写，未在本轮运行验证。周期必须大于零；示例把无效参数作为错误返回，避免直接触发 NewTicker 的参数 panic。

package main

import (
    "context"
    "fmt"
    "time"
)

// StartPeriodic 启动串行周期任务，调用方负责取消并等待完成。
func StartPeriodic(ctx context.Context, interval time.Duration, work func(context.Context)) (

示例故意使用短暂 Sleep 模拟主程序运行时间，它不保证精确执行次数。可预期的检查点是：取消后能够收到 done，且最终的完成提示发生在循环退出之后。不要把“执行了三次”写成验收条件，线程调度、任务耗时和 tick 丢弃都可能改变次数；本文没有给出实测输出或性能结论。

变体卡：已有 stop 通道怎样接入

若业务已经有只读的 stop 请求通道，可以把 select 中的 ctx.Done 分支换成 stop，同时继续保留单独的 finished 完成通知。请求通道由约定的唯一发起方关闭，finished 则由循环关闭。多个调用者都可能发起关闭时，需要统一入口或 sync.Once，不能让每个调用者直接 close 同一通道。

更简洁的选择通常是复用 context.WithCancel 返回的 cancel；它允许重复调用，调用方不必管理通道关闭竞争。不过，cancel 依然只发出请求，不等待消费循环退出。不要在 work 内部调用“取消并等待当前 done”的组合函数，否则当前回调等着自己返回后才会触发的完成通知，会形成自等待。

兼容坑：不要把 ticker 当成任务队列

Ticker 面对慢接收者可以调整间隔或丢弃 tick，它不承诺每个周期都积攒成一条待执行任务。这里的串行循环适合周期刷新、状态巡检一类“按机会执行”的工作；不能直接承担必须逐条处理、逐条确认的任务队列职责。

旧版本及兼容计时器行为可能影响通道缓存相关细节；本配方不依赖通道容量、清空残留 tick 或 Stop 返回布尔值。注意 Ticker.Stop 没有返回值，不要套用 Timer.Stop 的代码模式。无论采用何种版本，核心退出协议都应独立于 ticker.C 是否还有可接收事件。

最终只需要守住三个边界：Stop 结束周期事件源，取消信号让消费循环获得退出条件，done 让调用方确认清理和循环返回。三者配合，才是可交代的生命周期，而不是单独增加一行 defer。