Go context.AfterFunc 取消后如何确保清理只执行一次

如果一个资源既要在 Context 取消时清理，又允许调用方主动 Close，关键不是给两个入口各写一遍释放代码，而是让它们汇聚到同一个幂等函数：stop() 只负责阻止尚未启动的回调，sync.Once 保证真实清理最多执行一次，done 则在需要同步时告诉调用方回调已经结束。

先分清 stop 的返回值，再决定谁执行清理

context.AfterFunc(ctx, f) 会在 ctx 取消后用独立 goroutine 调用 f。它返回的 stop 函数有一个容易误读的边界：返回 true 只表示这次调用成功解除关联，回调不会再被启动；返回 false 表示回调已经启动，或者此前已经停止。后者不等于“回调已经执行完”。

把真实释放逻辑集中到 sync.Once

下面用一个资源对象代替连接、临时目录或文件句柄。构造时只注册一次 AfterFunc，所有释放动作都进入 cleanup。即使两个 goroutine 同时调用 Close，或者取消和主动关闭恰好撞在一起，once.Do 也只会放行一次真实释放。

package resource

import (
    "context"
    "sync"
)

type Resource struct {
    stop func() bool
    once sync.Once
    done chan struct{}
}

func New(ctx context.Context) *Resource {
    r := &Resource{done: make(chan struct{})}
    // 取消发生后由 AfterFunc 在独立 goroutine 中触发同一个清理入口。
    r.stop = context.AfterFunc(ctx, r.cleanup)
    return r
}

func (r *Resource) cleanup() {
    r.once.Do(func() {
        // 这里替换成关闭连接、释放句柄等真正的一次性动作。
        releaseResource()
        // 通知等待者：清理动作已经完整结束。
        close(r.done)
    })
}

func (r *Resource) Close() {
    // true 表示回调被阻止，此时由主动关闭路径执行清理。
    if r.stop() {
        r.cleanup()
    }
    // false 可能意味着回调已启动；等待不会把 stop 变成同步函数。
    

这个例子中的 releaseResource 代表业务资源释放函数，实际代码应让它本身返回错误或记录失败状态。Close 无论走哪条竞态分支都会等到 done 关闭，因此调用方拿到返回时，可以把“资源已完成释放”作为契约。

用 done 通道让 Close 等到真正清理完成

stop 不等待 f 返回，这是官方文档特别强调的语义。若资源关闭后还要马上复用同一文件、连接或锁，单独判断 stop() == false 不够，必须由回调在最后关闭一个只读完成信号。上面的 done 是一次关闭通道：只要 cleanup 通过 sync.Once 进入，等待者最终都能收到完成通知。

有一个实用边界：如果业务只要求“最多释放一次”，不要求 Close 返回前等待，可以去掉 ；如果清理动作可能阻塞，则应把阻塞时间、错误传播和调用方超时策略一起设计，不能把通道等待当成自动超时。

三个容易踩到的并发坑

• 无条件执行 cleanup：先调用 stop，又无条件调用清理，会让不同入口重复操作；即便 cleanup 暂时看似安全，也会掩盖资源状态竞态。
• 把 false 当成完成：false 只说明停止动作没抢到“尚未启动”的窗口，回调仍可能在另一个 goroutine 中执行。
• 重复注册 AfterFunc：同一个 Context 上多次注册不会互相替换，每个回调都独立存在；资源对象应把注册位置收敛到构造函数。

延伸问答

AfterFunc 回调会阻塞取消操作吗？

回调在自己的 goroutine 中运行，取消方不会因为等待回调结束而自动同步；需要确定完成时，要像示例一样显式协调。

只使用 sync.Once，不调用 stop 可以吗？

可以避免真实清理重复，但不能解除回调与 Context 的关联，也不能避免无意义的回调 goroutine。主动关闭路径仍应先调用 stop。

done 通道能不能由 Close 关闭？

不建议。取消回调和主动路径都可能到达清理逻辑，由唯一的 cleanup 在一次性区域内关闭 done，才能避免通道重复关闭。

记住这条判断即可：stop 决定谁获得清理入口，sync.Once 决定入口只放行一次，done 决定调用方是否等待到动作完成。