AfterFunc 回调与 Stop 同时发生时怎样避免重复清理

避免重复清理的关键，不是根据 Stop 的返回值让两条路径各做一套清理，而是让“正常返回”和“Context 取消回调”都调用同一个幂等 cleanup。我会用 sync.OnceFunc 包住实际释放动作，再用 done 通道表示清理完成；收尾时先调用 stop()，随后无条件调用 cleanup() 并等待完成。

这样即使 context.AfterFunc 的回调与 Stop 同时发生，也只有一个调用者真正执行释放动作，另一个调用者会等待同一次清理结束。不要把 stop() == false 理解成“清理已经完成”，因为官方语义只是回调已经开始，或者关联此前已经被停止。

官方文档：https://pkg.go.dev/context#AfterFunc

Stop 只解除关联，不代表清理已结束

我第一次用 AfterFunc 时，把 stop() 当成了“停止并等待”。这种理解会让资源在回调仍运行时被下一段逻辑继续使用。它实际返回的是一个竞争结果：

更容易忽略的是，AfterFunc 回调运行在自己的 goroutine 中。即使 stop() 返回 false，调用方也会立即继续，不会替你等待释放连接、归还锁或写完最后一条记录。需要完成确认时，必须自己提供通道、WaitGroup 或其他同步信号。

让正常收尾和取消回调共用一个 cleanup

我现在更倾向于让两个触发来源只负责“请求清理”，实际释放动作只有一个入口。下面的包装函数既覆盖正常返回，也覆盖取消和两者同时发生的情况：

package lifecycle

import (
    "context"
    "sync"
)

func runWithCleanup(
    ctx context.Context,
    work func(context.Context) error,
    release func(),
) (err error) {
    done := make(chan struct{})

    cleanup := sync.OnceFunc(func() {
        // 无论 release 正常返回还是触发 panic，都先发出完成信号。
        defer close(done)

        // 实际释放动作只允许执行一次，且不要反向等待 work 返回。
        release()
    })

    // Context 取消时，标准库会在独立 goroutine 中请求同一个 cleanup。
    stop := context.AfterFunc(ctx, cleanup)

    defer func() {
        // 尝试解除关联；即使回调已经启动，后面的 cleanup 仍是安全的。
        stop()

        // 正常路径也请求同一个清理入口；若另一路正在执行，这里会等待。
        cleanup()

        // 返回前显式确认释放动作已经结束。
        

这段写法故意不依赖 stop() 的布尔值决定谁清理。正常路径总会调用 cleanup；如果取消回调先进入，OnceFunc 会让正常路径等它执行完；如果 stop() 先成功，正常路径就成为唯一执行者。对我来说，这比维护两套分支状态更容易审查。

done 信号解决的是完成确认

sync.OnceFunc 已经能保证重复调用不会再次执行回调，并且并发调用会等待首次执行结束；这里保留 done，是为了把“清理完成”变成可共享的生命周期信号。其他只观察状态的 goroutine 可以选择等待 done，而不需要获得 stop 的调用权。

如果清理函数需要返回错误，可以用带缓冲的错误通道保存唯一结果，或者把清理入口改成 sync.OnceValue(func() error)。无论采用哪一种，都要定义第一次错误是否永久缓存；一次性原语不会自动重试失败的清理。

Stop 最好只有一个调用所有者

stop() 可以被调用多次，但第二个调用者看到 false 时，无法单凭这个值区分“回调已经开始”和“另一个调用者早已停止关联”。如果多个 goroutine 都把 false 当作等待回调的依据，逻辑很容易卡住。

我的取舍是让创建 AfterFunc 的那一层同时拥有 stop，并在一个固定的 defer 中调用它。其他组件只能调用幂等 cleanup 或等待 done。这样 Stop 的布尔值不再承担全局状态判断，资源所有权也更清楚。

回调里最容易出现的两个死锁点

第一类是 release 反向等待 work 返回，而 work 又要等资源释放后才返回。取消回调进入 release 后，两边形成循环等待。更稳妥的做法是让清理回调只发出取消、关闭底层阻塞资源或更新状态，不在里面等待业务 owner 完成。

第二类是清理继续使用已经取消的 ctx 发起 I/O。此时请求往往立刻失败，甚至让“收尾没有执行”看起来像竞争问题。确实需要网络或存储收尾时，可以从 context.WithoutCancel(ctx) 保留必要的值，再用 context.WithTimeout 建立短且独立的清理时限；对应的 cancel 必须释放。

另外，回调应避免 panic。因为它运行在独立 goroutine 中，未恢复的 panic 会影响整个进程。清理错误最好通过错误通道、日志或结果对象传递，而不是把 panic 当作跨 goroutine 的错误返回。

四种竞争场景这样复查

适合这种写法的是“清理不可重入、正常结束和取消都可能触发、调用方必须等到释放完成”的组件。如果清理天然幂等且无需等待，结构可以更简单；如果失败后需要重试或有多个中间状态，则应升级为显式状态机，而不是继续给一次性回调增加分支。

相关问题

stop 返回 false 后一定要等待回调吗？

如果后续操作依赖清理完成，就必须协调等待；但 false 也可能表示关联此前已停止，所以最好等待独立完成信号，而不是只解释布尔值。

stop 会中断已经运行的 AfterFunc 回调吗？

不会。回调一旦开始，stop 不能终止它，也不会等它返回。

只用 sync.Once 不用 done 可以吗？

如果所有需要确认完成的路径都会同步调用同一个 Once 包装函数，可以；若其他组件只观察状态，单独的 done 通道会让完成语义更清楚。

AfterFunc 回调里可以等待主 goroutine 吗？

通常不建议。主 goroutine 可能正在等待 cleanup 返回，双向等待很容易形成死锁；回调应保持单向通知和短小释放。