Golang Context.AfterFunc新特性_Go 1.21后的定时回调-Golang-PHP中文网

Context.AfterFunc 是 Go 1.21 新增的上下文清理钩子，用于在可取消 Context 被取消后立即同步执行一次回调，非定时器；必须由 context.WithCancel/WithTimeout 派生的 Context 调用，不可用于 Background/TOD0；回调阻塞 cancel 路径，需幂等且避免耗时或 panic。

golang context.afterfunc新特性_go 1.21后的定时回调

Context.AfterFunc 是什么，为什么现在才需要关注

Go 1.21 确实新增了 Context.AfterFunc，但它不是“定时器”，也不是 time.AfterFunc 的替代品。它的核心作用是：在 Context 被取消（或完成）后，**立即、同步、仅执行一次**某个回调函数。关键在于“上下文生命周期结束时的清理钩子”，不是“延迟执行”。很多人一看到 “After” 就默认是定时，结果发现函数没按预期延时调用，甚至 panic。

怎么正确调用 `Context.AfterFunc`

它必须由一个可取消的 Context（比如 context.WithCancel 或 context.WithTimeout）返回的派生 Context 调用；不能对 context.Background() 或 context.TODO() 直接使用，否则 panic：panic: context: invalid afterfunc on background or todo context。

常见写法：

ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second)
defer cancel()

// ✅ 正确：在可取消 ctx 上注册
ctx.AfterFunc(func() {
    log.Println("context 已结束，执行清理")
})

// ❌ 错误：Background() 不支持 AfterFunc
context.Background().AfterFunc(func() {}) // panic!

回调函数在 Context 取消那一刻被同步调用，不另起 goroutine
如果 Context 已经取消，AfterFunc 会立刻执行回调（且只执行一次）
同一个 Context 可多次调用 AfterFunc，所有回调都会被执行，顺序与注册顺序一致

和 `time.AfterFunc` / `defer` 的本质区别在哪

三者完全不是一类工具：

Golang Uber Dig

使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等

下载

time.AfterFunc：纯时间驱动，不管 Context 状态，到点就发 goroutine 执行
defer：绑定在函数退出时，但无法感知 Context 是否提前取消（比如 goroutine 被外部 cancel 中断，defer 仍等函数自然返回才触发）
Context.AfterFunc：绑定 Context 生命周期，cancel 一发生，立刻同步回调——适合资源释放、指标上报、状态归零等强一致性清理场景

举个典型坑：用 defer 关闭 HTTP 连接池的 idle conn，但如果 handler 因超时被 cancel，defer 还没触发，连接可能继续空闲占用；而 ctx.AfterFunc 能确保 cancel 后立刻清理 idle conn。