Go context.AfterFunc 怎样在取消时安排清理动作完成一个可复用的最小示例

如果一个请求取消后还需要关闭连接、撤销订阅或释放临时资源，可以用 context.AfterFunc 把清理动作绑定到取消信号上。它会在 ctx 被取消后，启动一个独立 goroutine 调用清理函数；如果上下文已经取消，清理函数也会异步启动，而不是改成当前 goroutine 同步执行。

官方地址：https://pkg.go.dev/context#AfterFunc

• 注册：AfterFunc 返回一个 stop 函数，用来解除尚未开始的关联。
• 取消：上下文取消后，清理函数在自己的 goroutine 中运行。
• 收尾：stop 不会等待清理函数执行完，需要用 channel、WaitGroup 或其它同步方式协调。

先把取消和清理放进同一条生命周期

把它看成一条数据生命周期会更容易：资源创建后注册清理动作，业务继续使用资源；收到取消信号后，清理动作从“已注册”进入“执行中”，最终发出“已完成”信号。这个生命周期不等于 defer：defer 依附当前函数返回，而 AfterFunc 依附上下文取消。

用最小示例安排取消后的清理动作

下面的例子用一个模拟资源表示连接或订阅。取消发生后，清理函数关闭资源并关闭完成通道；调用方用完成通道确认清理已经结束。示例只展示结构，不把输出当作运行截图或运行证据。

package main

import (
    "fmt"
    "sync"
    "time"
    "context"
)

type resource struct {
    once sync.Once
}

func (r *resource) close() {
    r.once.Do(func() {
        // 用 Once 保证取消回调和主动关闭不会重复释放同一资源。
        fmt.Println("resource closed")
    })
}

func main() {
    ctx, cancel := context.WithCancel(context.Background())
    defer cancel()

    res := &resource{}
    cleanupDone := make(chan struct{})

    stop := context.AfterFunc(ctx, func() {
        // AfterFunc 的回调在独立 goroutine 中执行。
        defer close(cleanupDone)
        res.close()
    })

    cancel() // 业务结束时触发绑定的清理动作。
    if !stop() {
        // stop 返回 false 时，回调可能已经开始；它本身不等待完成。
        

这里的 sync.Once 很重要：如果业务路径也可能调用 res.close()，取消回调就不应该再次执行同一份释放逻辑。生产代码中，完成通道通常由调用方持有，或者改用显式的关闭状态和等待组。

stop 的返回值不是“清理完成”标记

stop 返回 true，表示它成功阻止了清理函数运行；返回 false，表示上下文已经取消且清理函数可能已经启动，或者这个关联此前已经被停止。两种返回值都不代表清理函数已经执行完。

如果关闭资源后还要让上层返回成功，必须等待 cleanupDone 被关闭；如果清理只是后台的尽力而为动作，则可以不等待，但要明确它的失败记录和生命周期由谁负责。

放进服务代码时要守住三个边界

第一，清理函数要短而且幂等。它不适合承载长时间重试，也不要假设调用方仍在原来的请求 goroutine 中。第二，关闭资源和等待资源关闭是两件事：AfterFunc 只负责触发，完成通知仍需业务自行设计。第三，多个 AfterFunc 调用彼此独立，不会自动互相替换；同一个上下文注册多个清理动作时，应明确它们是否可以并发。

如果业务在上下文取消前主动完成，可以先调用 stop() 解除未执行的回调，再按正常路径释放资源。若 stop() 返回 false，就进入“回调可能已经执行”的分支，用幂等清理和完成信号处理竞态，不要再次无条件关闭底层句柄。

相关问题

AfterFunc 会阻塞取消调用吗？

不会。它安排清理函数在独立 goroutine 中运行；如果调用方必须等清理完成，需要额外的 channel、WaitGroup 或其它明确同步机制。

stop 返回 false 时一定代表清理已经完成吗？

不一定。它只说明回调可能已开始，或者关联已经停止；返回值没有提供完成保证。要判断完成，必须读取清理函数主动发出的完成信号。

为什么还需要 sync.Once？

主动关闭和取消回调可能同时到达。用 sync.Once 包住真正的释放动作，可以把这两个入口收敛到一次执行，避免重复关闭或重复回收。