Go 语言中 time.After、Timer 和 Ticker 怎么选？

超时控制、定时轮询、延迟执行，是 Go 服务里非常常见的需求。看起来只要 time.After、time.NewTimer、time.NewTicker 随手一写就能完成，但线上问题往往也藏在这些“顺手”代码里：循环中不断分配定时器、旧版本里忘记清理导致内存压力、重置 Timer 时读到过期事件、Ticker 退出后还在后台运行。

这篇文章围绕 Go 标准库 time 包，梳理 time.After、Timer 和 Ticker 的适用边界。尤其需要注意的是，Go 1.23 对 Timer/Ticker 的垃圾回收和通道语义做过重要调整，很多旧经验需要重新校准。

先看选择边界

可以先把三个常用 API 的定位说清楚。

time.After 适合一次性超时等待。它返回一个只读 Channel，到期后发送当前时间，代码非常短：

select {
case v := <-work:
    return v, nil
case <-time.After(200 * time.Millisecond):
    return "", context.DeadlineExceeded
}

这段代码适合“等一个结果，最多等多久”的场景。它的问题不在语义，而在使用频率：如果放在高频循环里，每次循环都会创建新的定时器对象，即使 Go 1.23 之后无引用定时器可以被垃圾回收，频繁分配本身仍然会制造额外开销。

需要取消、复用或重置超时时，应该使用 time.NewTimer。它返回 *time.Timer，开发者可以主动 Stop，也可以 Reset。

timer := time.NewTimer(200 * time.Millisecond)
defer timer.Stop()

select {
case v := <-work:
    return v, nil
case <-timer.C:
    return "", context.DeadlineExceeded
}

这段代码与 time.After 的结果类似，但 Timer 对象由调用方持有，后续可以用于更复杂的控制逻辑。

周期性任务则使用 time.NewTicker。Ticker 会按照固定间隔不断发送时间，直到调用 Stop。

ticker := time.NewTicker(time.Second)
defer ticker.Stop()

for range ticker.C {
    flushMetrics()
}

这段代码少了退出条件，只适合示意。真实服务里通常还要接入 context.Context，让任务可以随服务关闭而退出。

time.After 不再是老问题

过去有一个常见说法：循环里不要用 time.After，否则定时器到期前不会被回收，可能造成内存压力。这个提醒在老版本 Go 中有现实意义，但在 Go 1.23 之后需要改写。

官方文档已经明确说明：从 Go 1.23 开始，垃圾回收器可以回收未被引用、尚未到期的 Timer；因此仅从回收角度看，已经没有必要为了让 GC 回收而优先使用 NewTimer 再调用 Stop。Ticker 也一样，未被引用且未停止的 Ticker 可以被 GC 回收。

但这不等于 time.After 可以无脑放进热路径。下面这种写法语义正确，却会在每轮循环创建新的定时器：

for {
    select {
    case item := <-queue:
        handle(item)
    case <-time.After(time.Second):
        reportIdle()
    }
}

如果循环非常频繁，定时器的创建和清理仍然是成本。更稳妥的做法是复用一个 Timer，每轮按需重置。

timer := time.NewTimer(time.Second)
for {
    timer.Reset(time.Second)
    select {
    case <-queue:
        handle()
    case <-timer.C:
        reportIdle()
    }
}

这段代码展示的是 Go 1.23+ 的写法：Reset 返回后，后续从 timer.C 收到的值不会来自重置前的旧配置。对于新语义，复用 Timer 的主要价值是减少分配，而不是绕开 GC 无法回收的问题。

Reset 的版本差异

Timer 最容易写错的是 Stop 和 Reset。Go 1.23 之前，Timer 的通道是带缓冲的，Stop 或 Reset 之后，通道里可能还残留旧的时间值。为了避免读到过期事件，老代码经常需要先 Stop、再尝试 drain。

旧版本兼容写法通常长这样：

func resetTimer(t *time.Timer, d time.Duration) {
    if !t.Stop() {
        select {
        case <-t.C:
        default:
        }
    }
    t.Reset(d)
}

这段代码的核心是清掉可能已经进入 t.C 的旧事件。它适合需要兼容 Go 1.22 及更早语义的项目。

Go 1.23 之后，Timer 通道改为同步通道。官方文档保证：对基于 Channel 的 Timer，只要 Reset 返回，后续接收就不会拿到旧定时器配置产生的过期时间值。也就是说，新项目里可以直接 Reset，代码更简单。

不过版本差异还有一个容易忽略的开关：新语义只会在主模块 go.mod 声明 go 1.23 或更高版本时启用。即使使用较新的 Go 工具链，如果模块仍声明较旧版本，仍可能保留旧行为。维护老项目时，不能只看本机 go version，还要看 go.mod。

Ticker 要管生命周期

Ticker 的误区通常不是 GC，而是业务生命周期。Go 1.23 之后，未引用的 Ticker 可以被 GC 回收；但只要 goroutine 还在 range ticker.C，这个 Ticker 就仍然被引用，任务也仍然活着。

下面是更适合服务后台任务的写法：

ticker := time.NewTicker(time.Second)
defer ticker.Stop()
for {
    select {
    case <-ctx.Done():
        return
    case <-ticker.C:
        flushMetrics()
    }
}

这里的 Stop 不是为了“让 GC 能回收”，而是表达清晰的生命周期：任务退出时，周期信号也随之停止。官方文档还特别说明，Stop 不会关闭 Ticker.C，这样可以避免并发接收方误读到一个零值时间。

因此，不能用 range ticker.C 等待 Stop 后自动退出。range 只有在 Channel 关闭时才结束，而 Ticker 的 Channel 不会因为 Stop 被关闭。后台任务要退出，应显式监听 context.Context、退出 Channel 或其他生命周期信号。

AfterFunc 不是普通 Timer

time.AfterFunc 看起来也返回 *time.Timer，但它和 NewTimer 的行为不同。NewTimer 到期后向 C 发送时间；AfterFunc 到期后会在自己的 goroutine 中执行函数，并且它返回的 Timer 的 C 字段不会被使用。

延迟清理资源时，AfterFunc 很方便：

timer := time.AfterFunc(5*time.Second, func() {
    cleanup(reqID)
})
defer timer.Stop()

这段代码表示：如果外层逻辑提前结束，就尝试取消延迟清理；如果已经到期，清理函数可能已经开始执行。

这里的关键点是：Stop 不会等待函数执行完成。如果 Stop 返回 false，说明 Timer 已经过期并且回调函数已经开始执行，而不是表示 Timer 已经被停止。需要等待回调结束时，应自己加同步信号。

done := make(chan struct{})
timer := time.AfterFunc(time.Second, func() {
    defer close(done)
    cleanup(reqID)
})
if !timer.Stop() {
    <-done
}

这段代码只适合确认回调一定会关闭 done 的场景。实际封装时还要避免回调未启动而等待 done 造成阻塞。更通用的做法，是通过互斥锁、sync.Once 或状态机管理回调和取消之间的竞态。

AfterFunc 的 Reset 也要谨慎：如果 Timer 仍处于活动状态，Reset 会重新安排执行时间；如果已经到期或停止，Reset 会再次安排函数执行。官方文档明确提醒，Reset 不会等待上一次函数执行完成，也不保证下一次执行与上一次不并发。回调函数如果会改共享状态，必须自己保证并发安全。

实战建议

可以把 Timer 相关代码按场景做选择。

一次性等待，优先使用 time.After。代码短，语义清晰，适合普通请求超时、简单 select 分支。

高频循环、需要复用、需要提前取消或动态调整时间，使用 time.NewTimer。Go 1.23+ 可以简化 Reset 逻辑；兼容老模块时仍要保留 Stop 和 drain。

周期性任务使用 time.NewTicker，并且配合 context.Context 管生命周期。Stop 不会关闭 Channel，因此不要把退出逻辑建立在 range ticker.C 自动结束上。

延迟执行函数使用 time.AfterFunc，但要记住它会启动 goroutine 执行回调。Stop 不等待回调结束，Reset 也不保证回调之间不并发。

还有一个工程细节：如果项目已经使用 context.WithTimeout 或 context.WithDeadline，通常不需要再额外包一层 time.After。标准库的 context 已经负责超时取消，业务代码只要监听 ctx.Done() 即可。

ctx, cancel := context.WithTimeout(parent, time.Second)
defer cancel()

select {
case <-ctx.Done():
    return ctx.Err()
case v := <-work:
    return use(v)
}

这段代码把超时语义交给 context，调用链上的数据库、HTTP 请求和其他下游操作也能共享同一个取消信号，比局部 time.After 更容易形成统一治理。

写在最后

Timer 代码的问题，通常不是 API 不够用，而是生命周期和版本语义没有想清楚。

Go 1.23 之后，time.After 和未停止 Ticker 的 GC 压力已经明显改善，旧版本里的很多“必须 Stop 才能回收”说法需要更新。但在高频循环里，time.After 仍然可能带来分配成本；在老模块里，Reset 仍然要考虑旧的缓冲通道语义；在后台任务里，Ticker 仍然需要显式退出信号；在 AfterFunc 里，回调并发安全仍然要由业务代码负责。

一句话总结：time.After 适合简单一次性等待，Timer 适合可控超时，Ticker 适合周期任务，AfterFunc 适合延迟回调。选对 API，再守住 Stop、Reset 和生命周期边界，定时器代码才会稳定。