Go time.After 会不会泄漏定时器：一次性等待与长循环的资源边界

定时任务每隔几秒检查一次队列时，代码里常会出现一行很顺手的 case 。一次等待结束后函数就返回，这样写很清楚；但如果这行代码位于永不退出的 for 循环里，问题就从“多久醒一次”变成了“每一轮创建的定时器由谁收尾”。

time.After 不是看到就该替换的危险 API：短生命周期、一次性等待可以直接用。真正需要调整的是长循环或可取消任务，此时用一个可停止、可复用的 time.Timer，并把 Stop、Reset 与 ctx.Done 放进明确的退出路径。

一次性等待：time.After 为什么读起来最自然

先看一个等待上游结果的函数。它只等待一次，收到结果或上下文结束就返回，定时器没有机会被循环反复创建：

func waitResult(ctx context.Context, result 

这里的控制流只有三个出口：result 先到就返回数据，time.After 先到就返回超时，ctx.Done 先到就把取消原因交给调用方。函数返回后，调用方也不再持有这个等待过程。对于这种“一个请求只等一次”的场景，代码短反而更容易验收。

长循环里的变化：每次 time.After 都会创建新的等待

把相同写法搬进循环，生命周期就不再是一次函数调用：

for {
    select {
    case job := 

每次执行到 time.After，都会得到一个新的只读时间通道和对应的计时器。若 jobs 很忙，循环可能在旧计时器到点前就进入下一轮，新的计时器又被创建出来。现代 Go 运行时会在不可达对象上做回收，这不等于业务可以把这种创建模式当成“零成本”；高频循环中，持续分配和等待会让分配曲线变得难解释。

更重要的是，循环通常还有取消、重载配置或快速退出的需求。time.After 只给出等待通道，不给调用方一个明确的停止和重置入口。排查时别只问“有没有泄漏”，还要问“定时器是否在下一次业务动作前仍然存活”。

需要控制生命周期时：用 time.NewTimer 收拢退出路径

当循环需要一个可停止的周期等待，可以把计时器提到循环外：

func poll(ctx context.Context, jobs 

这个版本只有一个 time.NewTimer。收到任务后先尝试 Stop，如果计时器已经到点，非阻塞地清掉 timer.C 中可能残留的事件，再调用 Reset。定时分支消费了 timer.C 后也直接重置。函数退出时由 defer timer.Stop 兜底，ctx.Done 的取消路径因此是完整的。

示例里的 handle 和 checkQueue 都应当是本轮业务真正需要的短操作。如果它们可能长时间阻塞，计时器事件只会在通道里等待，不能把一次检查自动变成并发执行。

怎么选：看等待是否跨过一次函数调用

我通常先画出一个问题：这次等待结束后，持有它的函数是否也会结束？答案是“会”，time.After 往往足够；答案是“不会”，就把计时器当成长期资源管理，显式写出停止、清理、重置和取消。

常见问题

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

不能这样下结论。短生命周期的一次性等待通常没有这个问题；需要警惕的是长循环里反复创建、等待时间又较长的模式，它可能带来不必要的分配和延迟回收。

能不能把 time.After 换成 time.NewTimer 后只调用 Reset？

不能忽略旧事件。重置前先处理 Stop 的结果和 timer.C 中可能存在的事件，确保下一轮消费的是新的等待。

time.Ticker 和 time.Timer 应该怎么区分？

Timer 通常表示一次等待，消费后再决定是否重置；Ticker 表示持续产生 tick。若业务需要根据任务完成时间重新计时，Timer 更容易表达。

为什么还要监听 ctx.Done？

计时器只能表达时间到了，不能表达服务关闭、请求取消或上游失败。把 ctx.Done 放在同一个 select 中，才能让循环在非时间事件到来时及时结束。

小结

time.After 的关键不在于“能不能用”，而在于等待是否只发生一次。一次性请求中它让三个结果分支保持清楚；长循环中则应改用一个可停止、可重置的 time.Timer，把 Stop、通道清理、Reset 和 ctx.Done 写成完整控制流。这样做既减少重复创建，也让退出时到底收回什么资源变得可核对。