Go 问答：time.After 放进循环为什么会让定时任务越积越多

轮询任务通常写成一个无限循环：先处理一次任务，再等几秒进入下一轮。问题出在等待方式——如果每轮都调用 time.After，就会不断创建一次性计时器；当处理速度、取消逻辑和等待时间叠在一起时，内存曲线会比任务数量更早暴露异常。

time.After 适合偶尔的一次性等待；高频循环应把计时器提到循环外，用 time.NewTimer 配合 Stop、Reset 和 ctx.Done 管理生命周期。

轮询任务为什么会把 time.After 越用越多

先看一个最小的轮询骨架。pollOnce 只代表一次业务处理，真正的问题在等待表达式位于循环体内部。

func run(ctx context.Context) {
    for {
        pollOnce()
        select {
        case 

每次走到 time.After，都会创建一个新的定时器并返回它的接收通道。上一轮的通道一旦触发就失去业务引用，但在高频循环、较长等待或提前取消的组合下，短时间内可能存在大量尚未到期的计时器。它们不一定构成永久泄漏，却会把堆分配、定时器管理和垃圾回收压力推高。

先把等待职责从业务循环里拆出来

如果业务只需要固定间隔，并且不会在等待中响应取消，可以把问题简化为一个复用的 time.Timer。这里仍保留取消分支，因为后台任务通常需要在关闭服务时尽快退出。

func run(ctx context.Context) {
    timer := time.NewTimer(5 * time.Second)
    defer timer.Stop()

    for {
        pollOnce()

        select {
        case 

这个版本只有一个计时器对象。每次收到 timer.C 后再 Reset，退出路径统一由 defer timer.Stop() 收口。若 pollOnce 自身可能运行很久，还应先确认它是否也能接收同一个 ctx，否则外层取消只能打断等待，不能打断业务处理。

Stop 和 Reset 之间最容易写错的边界

不要把 Stop 当成“无条件清空通道”。当计时器已经触发，事件可能已经进入通道，下一次 Reset 前要先按当前 Go 版本文档和代码路径处理残留事件。对这个示例来说，Reset 只发生在明确收到 timer.C 的分支，因此没有另一个 goroutine 同时操作该计时器，边界比较简单。

如果代码后来变成“提前重置本轮等待”，应把清理写成独立函数，并保持所有 Stop、接收旧事件和 Reset 操作都在同一控制路径里。不要从多个 goroutine 直接共享一个 timer；共享的不是一个无状态数字，而是一个有事件状态的对象。

用测试确认轮询、取消和清理都有效

性能问题不能只靠肉眼看代码。至少加一个短间隔测试，记录已经完成的轮询次数，再在等待期间取消上下文，确认 run 能返回。示例使用一个可替换的 pollOnce 闭包，避免测试真的访问外部系统。

func TestRunStopsOnCancel(t *testing.T) {
    ctx, cancel := context.WithCancel(context.Background())
    done := make(chan struct{})
    go func() {
        run(ctx)
        close(done)
    }()

    time.Sleep(20 * time.Millisecond)
    cancel()

    select {
    case 

实际项目里建议把等待时长和 pollOnce 注入配置，把测试从 5 秒缩短到几十毫秒；生产参数仍由正式配置提供。验收时重点看三件事：取消后 goroutine 是否退出、轮询计数是否符合预期、长时间运行时堆对象是否随轮数异常抬升。

常见问题：time.After 什么时候仍然合适

一次 HTTP 超时可以用 time.After 吗？

可以。单次请求或低频任务里的 select 等待很适合用它；真正需要复用和提前停止时，再换成 time.NewTimer。

time.After 一定会造成内存泄漏吗？

不能这样下结论。它创建的是一次性计时器，关键要看调用频率、等待时长和是否提前退出。高频循环里的大量未到期计时器会增加资源压力，但不等于每次调用都永久泄漏。

为什么不直接用 time.Sleep？

time.Sleep 无法在等待期间监听 ctx.Done，服务关闭时响应较慢。需要取消、超时或多个事件竞争时，应使用 select。

发布前的检查清单

• 循环是否在每轮创建了新的 time.After？
• 取消分支是否与 timer.C 并列，并且能实际关闭运行 goroutine？
• time.Timer 是否只由一个控制路径操作，Stop 是否覆盖退出场景？
• 压测或长时间测试是否同时记录轮询次数、goroutine 数和堆对象趋势？