time.AfterFunc 不泄漏但高频创建会导致 goroutine 积压；它自动 Stop() 无需手动清理，但不可复用；高频场景应改用 context.WithTimeout；若保存 *Timer 则必须显式 Stop()。
time.AfterFunc 本身不泄漏，但高频创建会堆积 goroutine
time.AfterFunc 底层调用 time.NewTimer，执行完回调后自动 Stop() 并释放资源，所以它**不需要手动 Stop**，也不会因“忘记清理”而泄漏。但问题出在高频调用：每次调用都新建一个 *Timer，背后绑一个 goroutine 和 channel；若每秒调用上百次（比如事件驱动重试、日志采样），未触发的 timer 会卡在 runtime timer heap 中，直到超时或 GC 扫描到无引用——而 GC 不会提前回收活跃 timer。
- 典型场景：HTTP handler 中为每个请求启动
time.AfterFunc(5 * time.Second, cleanup)，QPS 上千时 goroutine 数线性上涨 - 现象：
runtime.NumGoroutine()持续增长，pprof -goroutine显示大量runtime.timerproc - 根本原因：不是函数写错了，而是“创建太勤、生命周期太短”，timer 还没触发就被新请求覆盖，旧实例滞留内存
复用 timer 实例不可行，必须换思路
time.AfterFunc 返回的是 *Timer，理论上可复用——但实际不能。因为它的设计语义是“单次延迟执行”，且 Reset() 行为与 AfterFunc 的回调绑定逻辑冲突：你无法安全地把新函数塞进旧 timer，也没有 API 支持替换回调。
- 错误尝试：
timer.Reset(d); timer = time.AfterFunc(d, newFn)—— 第二行又新建 timer，完全没复用 - 强行复用回调函数 +
Reset()：需自己管理闭包状态，极易出竞态或漏清空 channel，得不偿失 - 正确取舍：接受
AfterFunc的“一次性”本质，把复用压力转移到上层逻辑
替代方案：用 context.WithTimeout + goroutine 控制更可控
当需要“延迟执行 + 可取消 + 高频复用”时，time.AfterFunc 不是最佳选择。context.WithTimeout 更适合：它底层也用 time.NewTimer，但 cancel 时自动 Stop()，且 ctx.Done() 是只关闭一次的 channel，多次接收无副作用。
- 示例：代替每请求一个
AfterFunc
func handleRequest(ctx context.Context) {
// 延迟 5 秒执行清理，但可随请求取消
timeoutCtx, cancel := context.WithTimeout(ctx, 5*time.Second)
defer cancel() // 自动 Stop 底层 timer
<pre class="brush:php;toolbar:false;">go func() {
select {
case <-timeoutCtx.Done():
if errors.Is(timeoutCtx.Err(), context.DeadlineExceeded) {
cleanup()
}
}
}()}
立即学习“go语言免费学习笔记（深入）”；
context.WithTimeout 适合有明确上下文边界（如 HTTP 请求、RPC 调用）的场景；纯后台循环仍需手动管理 *Timer
真正要盯住的泄漏点：timer.Stop() 被忽略或调用时机错
如果你确实保存了 time.AfterFunc 返回的 *Timer（比如用于取消重试），就必须显式调用 timer.Stop()——而且**无论是否已触发，都必须调**。很多人以为“回调已执行就不用 Stop”，这是错的：底层 goroutine 和 channel 仍被 runtime timer heap 持有，GC 不会回收。
- 安全模式：所有退出路径前都调
timer.Stop()，包括return、break、case - 更稳妥写法（处理已触发但 channel 未读完）：
if !timer.Stop() {
select {
case <-timer.C:
default:
}
}timer.Stop() 不关闭 channel，也不消费值；若忽略返回值直接丢弃 timer，残留信号可能在后续 select 中意外命中真正容易被忽略的是：time.AfterFunc 看似省事，但一旦进入高频、长周期、需取消的场景，它反而比显式管理 *Timer 更难控制资源。与其纠结复用，不如从设计上让延迟任务与 context 对齐，或者改用 time.Ticker + 任务队列做节流。
