Go context.AfterFunc 适合在哪些退出路径执行清理

如果一段 Go 代码需要在 Context 取消时打断阻塞操作、释放临时资源或通知另一个 goroutine，context.AfterFunc 很合适。它不适合替代所有 defer：正常完成时应调用返回的 stop 解除关联，取消已经发生时则必须把清理动作和“清理已完成”分开处理。

先分清取消触发、停止注册与清理完成

AfterFunc 从 Go 1.21 起进入标准库。调用它会得到一个 stop func() bool。正常路径先完成业务，再调用 stop；如果返回 true，说明取消清理还没有启动。若返回 false，可能是 Context 已取消、清理函数已经启动，也可能是此前已经停止过。这个返回值不承担等待职责。

生产代码最容易漏掉的地方，是把 stop() == false 当成“清理已经结束”。例如清理函数还在关闭连接，而外层函数已经把连接放回池中，就会产生竞态。需要另设完成信号，让资源所有者明确知道什么时候可以继续。

正常完成时用 stop 解除清理关联

下面的例子把取消动作绑定到网络连接的读操作。取消发生时，设置一个已经到期的读截止时间，让阻塞的 Read 返回；正常读完则通过 stop 取消这次绑定。

func readWithCancel(ctx context.Context, conn net.Conn, buf []byte) (int, error) {
    cleanupDone := make(chan struct{})
    stop := context.AfterFunc(ctx, func() {
        // 取消时让阻塞读尽快返回，避免清理动作卡在连接上。
        _ = conn.SetReadDeadline(time.Now())
        close(cleanupDone)
    })

    n, err := conn.Read(buf)
    if stop() {
        // 正常完成路径：清理尚未启动，解除 Context 与清理函数的关联。
        return n, err
    }

    // stop 为 false 只说明清理已启动或已停止，不能代替等待。
    

这个模式的关键不是“超时后一定执行某个函数”，而是把资源状态分成两条路径：读操作自己正常结束时，清理函数不能再介入；取消路径中，清理函数负责解除阻塞，调用方再等待清理完成并恢复连接状态。

把 AfterFunc 放进可回滚的资源生命周期

连接只是一个例子，同样的边界也适用于临时文件、条件变量等待、锁外通知和合并多个取消信号。清理函数里不要依赖已经失效的请求对象，也不要把长时间重试、业务回调等新工作塞进去。它最好只做“取消后必须做”的补偿动作，并能安全地重复调用或被并发观察。

使用共享状态时，建议把“修改资源状态”和“通知完成”放在同一个清理协议中。若需要多个清理动作，不要假设它们有注册顺序；可以用 sync.WaitGroup 统一等待，或为每个动作设计自己的完成 channel。

上线前用这张表检查退出路径

还要注意，AfterFunc 返回的 stop 函数不会等待清理函数结束；如果资源马上要交给下一个请求，必须先完成显式同步。对于必须与主流程同一 goroutine、并且无论什么返回都要执行的动作，defer 往往更直接。

常见问题

AfterFunc 会阻塞当前 goroutine 吗？

不会。取消后清理函数在自己的 goroutine 中运行，调用方需要自行决定是否等待。

stop 返回 false 是否一定说明 Context 已取消？

不一定，也可能是 stop 之前已经调用过。要判断取消原因，应读取 ctx.Err() 或在使用 cause API 时读取 context.Cause(ctx)。

清理函数里可以直接关闭共享连接吗？

可以，但必须明确连接的所有权并保证关闭操作与正常路径互斥或幂等，否则容易出现重复关闭、状态恢复覆盖或连接池竞态。