time.After 在高并发下会导致内存泄漏，因其底层 timer 未被消费时无法被 GC 回收；应改用 time.NewTimer + Stop()、time.Ticker 或 context.WithTimeout 按场景精准控制生命周期。
time.After 会悄悄吃内存？别让定时器变成 Goroutine 泄漏源
是的，time.After 在高并发场景下确实可能引发内存持续增长——不是它本身有 bug，而是它的底层实现（time.NewTimer(d).C）创建的 timer 对象，在未被消费前无法被 GC 回收。当你的 select 分支提前从其他 channel（比如 receiver.updated）退出时，time.After(5 * time.Second) 对应的 timer 仍在后台运行，直到 5 秒后往已无人监听的 channel 发送时间值，才真正释放。压测中常看到 RSS 内存阶梯式上涨，就是这个原因。
- 高频调用
time.After（如每请求都起一个）→ 大量 timer 堆积 → GC 延迟回收 → 内存毛刺甚至 OOM - 尤其在 HTTP handler、消息消费循环、健康检查轮询等长生命周期 goroutine 中风险最高
- Go 1.22+ 虽优化了 timer 管理，但该行为逻辑未变，仍需手动干预
替代方案：用 time.NewTimer + Stop() 精确控制生命周期
把“一次性定时器”从黑盒变成可管理对象，核心就两步：显式创建、显式终止。相比 time.After 的简洁，这是多写两行代码换来的稳定性。
func waitWorking() {
timer := time.NewTimer(5 * time.Second)
defer timer.Stop() // 防止 panic: stop called on stopped timer
select {
case <-timer.C:
_ = receiver.CheckWorkingEventBus.Publish(receiver)
case <-receiver.updated:
// timer 未触发，主动 Stop，通知 runtime 可回收
timer.Stop()
}}
-
timer.Stop()返回bool：true 表示 timer 尚未触发，成功取消；false 表示已触发或已停止，无需处理 - 务必在所有退出路径调用
Stop()，包括 defer（但 defer 中调用需加判空或 recover） - 不要复用 timer 实例跨 select 循环——每次都需要
time.NewTimer新建
高频轮询场景：优先用 time.Ticker，而非反复 new time.After
如果你的任务本质是「每隔 N 秒执行一次」（比如心跳上报、状态轮询、指标采集），time.After 或 time.NewTimer 都是错的抽象——它们是一次性的，每次都要重建 timer。正确姿势是复用单个 time.Ticker，它背后只跑一个 goroutine 持续发信号，开销极低。
立即学习“go语言免费学习笔记（深入）”；
ticker := time.NewTicker(5 * time.Second) defer ticker.Stop()for { select { case <-ticker.C: _ = receiver.CheckWorkingEventBus.Publish(receiver) case <-receiver.updated: return } }
-
time.Ticker的底层是全局 timer heap + 单 goroutine 调度，比 N 个独立 timer 节省 90%+ 调度开销 - 注意：不要在循环里
time.Sleep替代 ticker——sleep 不响应 cancel，且精度差、不可靠 - 若需动态调整间隔（如退避重试），则必须停掉旧 ticker，新建新 ticker
更复杂的超时/取消需求？直接上 context.Context
当定时逻辑嵌套在多层调用、需要支持主动取消、或要与 HTTP 请求、数据库查询等天然支持 context 的操作协同时，time.After 和 time.NewTimer 就显得力不从心了。此时 context.WithTimeout 或 context.WithDeadline 是更统一、更安全的选择。
ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second) defer cancel()select { case data := <-ch: process(data) case <-ctx.Done(): log.Println("timeout:", ctx.Err()) // 自动包含 ErrDeadlineExceeded }
- context 会自动管理 timer 生命周期：cancel() 后 timer 立即停止，无残留
- 适合跨 goroutine 传播取消信号，比如主流程 cancel 后，所有子任务同步退出
- 避免混用：不要在同一个 select 里既监听
ctx.Done()又监听time.After，语义重复且易出错
真正容易被忽略的点是：很多团队把 time.After 当成“语法糖”无脑用，却没意识到它在高并发服务里是个隐性内存放大器。是否要用 NewTimer、Ticker 还是 context，取决于你是在做「单次延迟」、「周期性轮询」还是「上下文感知的协作超时」——选错抽象，后期排查成本远高于初期多写的那几行代码。
