Context.AfterFunc 是 Go 1.21 新增的上下文清理钩子，用于在可取消 Context 被取消后立即同步执行一次回调，非定时器；必须由 context.WithCancel/WithTimeout 派生的 Context 调用，不可用于 Background/TOD0；回调阻塞 cancel 路径，需幂等且避免耗时或 panic。
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 的本质区别在哪
三者完全不是一类工具：
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
-
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。
容易忽略的并发与 panic 风险
AfterFunc 的回调是同步执行的，所以它会阻塞 Context 取消路径（比如 cancel() 调用本身）。如果回调里做了耗时操作（如网络请求、锁竞争、死循环），整个 cancel 流程会被拖住，影响上层超时控制或 graceful shutdown。
- 别在回调里调用阻塞 I/O 或长耗时逻辑；真需要异步，显式起 goroutine（并注意 Context 传递）
- 回调中 panic 不会传播，但会终止当前回调执行，后续注册的回调仍会运行
- 如果回调依赖其他已销毁对象（如已 close 的 channel、已 free 的 C 内存），需自行加保护逻辑
最常被漏掉的一点：AfterFunc 注册后无法取消或撤销。一旦注册，就一定会执行——哪怕你后来又重新 cancel 了这个 Context 多次，或者换了新 Context，旧注册依然有效。设计时得预判回调是否“幂等”。
