Go context.AfterFunc 怎样安排取消后的清理动作

Go 的 context.AfterFunc(ctx, f) 可以登记取消后的清理回调，但它不会等待清理完成，也不会替你处理清理错误。需要在函数返回前确认回收结果时，我会把返回的 stop 封装起来，再用完成通道协调正常返回与取消回调这两条路径。

官方文档地址：https://pkg.go.dev/context

AfterFunc 补上的是取消通知，不是自动回收

这项 API 在 Go 1.21 加入标准库，并不是最近才出现的新特性。对我来说，它值得采用的地方是：已经有一个上下文，又需要把它的取消信号接到不直接接收 Context 的清理接口上。不必为了这一处通知，给整个业务对象新增一套取消监听字段。

这里讨论一个有明确限制的接口设计：资源归当前任务所有；清理可以和业务逻辑并发；清理函数最终返回；调用方在离开任务时需要拿到清理错误。示例不是完整资源管理框架，也没有实际运行记录或性能结论。如果你的资源不允许在使用中关闭、注销或删除，应先让使用者退出，再清理，不能直接套用这个模型。

我会先分清注册、停止和完成三个对象

我最容易警惕的是把“取消发生了”理解为“清理已经做完”。AfterFunc 的回调在自己的 goroutine 中运行；注册时上下文已经取消，也仍是另外的 goroutine。一个上下文可以有多个独立注册，它们不相互覆盖，不能据此建立回调顺序。

正文把三个概念分别称为取消上下文、停止句柄和完成通道。注册回调属于取消关联，完成通道属于应用自己定义的同步协议。不要把停止句柄当成完成通道的替代品。

把 stop 留在内部，再给调用方一个 finish

下面的原创写法把正常返回也纳入清理责任。业务拿到的不是原始 stop，而是 finish：如果能够撤销回调，就在当前 goroutine 清理；否则等待回调的完成通道。两种情况最终都读取同一份返回错误。

package cleanup

import "context"

// Arm 约定 cleanup 非 nil、不 panic、最终能返回，并允许与业务并发。
// 返回的 finish 可以并发调用；它等待清理完成并返回同一份错误。
func Arm(ctx context.Context, cleanup func() error) func() error {
    done := make(chan struct{})
    var cleanupErr error

    run := func() {
        // 关闭通道表示函数已退出，不代表外部清理一定成功。
        defer close(done)
        cleanupErr = cleanup()
    }
    stop := context.AfterFunc(ctx, run)

    return func() error {
        // stop 只在此闭包内部使用，不能另行暴露给调用方。
        if stop() {
            // 正常返回抢到清理权：取消回调不会再运行。
            run()
        }
        // 抢不到清理权时等回调完成；通道也同步错误的读取。
        

使用时，在资源成功取得后调用 finish := cleanup.Arm(ctx, release)；在所有正常、错误返回出口调用 finish 并处理其错误。可以用 defer 保证出口覆盖，但如果采用匿名 defer，需明确错误是合并到命名返回值还是记录到日志，不能随手忽略。释放函数 release 的具体实现必须先符合上面的并发约定。

这段代码的关键不在通道有多复杂，而在 stop 没有逃出封装。第一次成功停止后，那个调用者负责执行 run；其他 finish 调用者停不下来，就等 done。如果取消回调已经取得运行资格，finish 同样只能等它。正因为外部不能单独调用 stop，才排除了“已经停止回调，却没人负责关闭 done”的分支。

cleanupErr 不需要另加一把锁来读：本例中只有取得清理权的一方写入，读者都先等待 done。不要把这个结论扩大到清理函数访问的其他业务字段，那些字段仍要各自满足并发同步要求。

我倾向于把契约保持窄一些：cleanup 不接收已经取消的 ctx，不代表它可以无限阻塞。如果内部还要请求远端服务，应在清理实现中定义独立且有界的超时策略；新建超时上下文仍须释放其取消函数。不要把“忽略取消”当作“保证最终成功”。

哪些地方继续用 defer 更合适

如果文件只在当前函数中使用，函数退出时关闭即可，普通 defer 往往更容易理解。为了少写一行 defer 引入异步回调，反而需要解释并发关闭和错误传递，我不会这么选。

sync.Once 可以把多个入口汇到一次动作，但它不能替你停止业务对资源的访问，也不能把一个阻塞的清理动作变快。上面的封装已经通过停止句柄决定清理权，因此没有再叠加 Once。不要同时让资源所有者、取消回调和另一个后台任务各自随意调用 release。

采用前，先把等待和并发代价写进接口

我会首先审视锁的使用。假如调用 finish 的位置持有业务锁，而 cleanup 也必须取得这把锁，等待就可能永远无法结束。不能靠“回调一般很快”消除这个环；应在调用 finish 前退出相应临界区，或者重新划分清理所需的状态。

其次是返回值的语义。Arm 不主动返回 ctx.Err()，finish 也不把取消当作清理失败。业务失败、任务取消与资源释放错误是三件事，由上层决定如何组合、记录和呈现。正常返回与取消并发时，哪一方取得清理权不影响本例“只清理一次并等待退出”的目标，但它不能为业务提交建立事务原子性。

最后是回调本身：它应短小、有界且不 panic。本例没有将 panic 恢复为 error；异步回调里的未恢复 panic 不是调用 finish 的外层 recover 能接住的。完成通道只是进程内同步，不是持久队列。进程退出、崩溃或被强制结束后，不能指望回调继续回收外部资源，需要资源期限、补偿任务或其他独立机制。

接入时可自行覆盖这些场景：注册前已取消、正常结束且未取消、取消与 finish 并发、多个 finish 并发、清理返回错误、清理被人为阻塞。本文只提供设计推演和代码，没有把这些场景声称为已经执行通过的测试。

相关问题

只写 defer stop() 可以吗？如果仅想撤销一项不再需要的通知可以；如果这个回调承担了唯一清理责任，stop 成功反而表示它不会清理，仍须安排正常路径。

cancel() 返回能证明回调结束吗？不能。需要完成结果，就和回调约定同步对象，而不是用 sleep 猜测。

同一 ctx 注册两个清理动作可以指定顺序吗？不要依赖注册顺序。存在依赖时，把动作放到一个自己控制顺序和错误策略的清理函数里。

共享连接能直接在回调里关闭吗？只有所有权和并发使用规则允许时才行。取消某个请求不能成为关闭所有请求共享资源的理由。

我的取舍是：只需要出口清理时保留 defer；确实需要对取消做适配时再使用 AfterFunc，并把停止权、完成通知和错误接收一起设计。让调用方能说明“谁清理、谁等待、谁处理失败”，比多注册一个回调更重要。

参考：context.AfterFunc 官方接口说明；Go 1.21 的 context 变更；sync.Once 官方说明。