Go context.AfterFunc 停止失败时如何判断回调是否已开始

结论先说：context.AfterFunc 返回的 stop() 如果是 false，只表示回调已经进入“不能再被阻止”的竞争结果；它不等于回调已经执行完，也不直接告诉你函数体的第一行是否已经运行。要判断“已开始”，需要在回调入口主动关闭 started；要判断“已结束”，再用 finished 做完成握手。

stop 返回值为什么不能代替回调状态

AfterFunc 会在 ctx 取消后以独立 goroutine 调用 f。返回的停止函数只负责解除“上下文取消与回调之间的关联”：返回 true，说明这次调用成功阻止了回调；返回 false，说明取消路径已经取得先手，或者这个停止函数此前已经成功使用过。

因此，下面这段判断只能回答“还能不能阻止”，不能回答“回调执行到哪了”。官方文档还特别说明，stop 不会等待 f 完成。

用 started 判断回调是否已经进入函数体

如果调用方只关心回调是否已经开始，可以在回调第一行关闭一个只读通道。关闭通道是一次性事件，多个接收方都能观察到；不要把 stop() == false 直接当成这个事件。

started := make(chan struct{})
finished := make(chan struct{})

stop := context.AfterFunc(ctx, func() {
    close(started) // 先发出“已经进入回调”的信号
    defer close(finished) // 无论后续如何返回，都标记回调收尾

    // 这里执行取消后的清理动作，不要假设 stop 会等待它完成。
    releaseLocalResource()
})

if stop() {
    // 本次 stop 成功，回调不会再从这个注册点启动。
    return
}

// stop 失败只代表回调不可再阻止；等待入口信号才能确认它真的开始。

这个模式把两个问题拆开：started 表示回调已经跑到第一行，finished 表示回调执行了收尾点。若只需知道“已开始”，收到 started 后即可继续；若调用方要接管回调正在触碰的连接、文件或状态对象，就必须等 finished。

用完成握手处理取消竞态

更常见的场景是：主流程正在使用资源，取消后由 AfterFunc 修改资源状态，而主流程退出时还要把资源恢复。此时最危险的写法是 if !stop() { reset() }，因为回调可能刚启动，reset 会与它并发访问同一对象。

func runWithCleanup(ctx context.Context, reset func()) error {
    started := make(chan struct{})
    finished := make(chan struct{})

    stop := context.AfterFunc(ctx, func() {
        close(started) // 记录回调确实进入了函数体
        defer close(finished) // 调用方可据此安全等待回调退出
        interruptBlockedWork()
    })

    err := doWork(ctx)
    if stop() {
        // 工作先结束，取消回调被阻止，资源可直接交回调用方。
        reset()
        return err
    }

    // 取消先发生：先确认回调已进入，再等待它完成。
    

这里的 started 不是为了制造额外日志，而是为了把“回调已被调度”变成调用方可以等待的事实；finished 才是资源交接的边界。回调内部如果有多个清理动作，应该把它们放在 defer close(finished) 之前。

三个容易误判的边界

1. 重复调用 stop。第一次可能返回 true，第二次返回 false；第二次的 false 不表示回调突然开始。
2. 只等待 started。它只能证明入口已到达，不能证明清理动作已经完成；共享资源交接应等待 finished。
3. 回调内部 panic。defer close(finished) 仍会执行，但 panic 会在独立 goroutine 中影响进程；生产代码应让回调自身具备清晰的错误与恢复策略。

判断标准可以浓缩成一句话：stop 负责争夺“是否还能阻止”，started 负责确认“是否进了函数体”，finished 负责确认“是否可以交接资源”。三者不要互相替代。

常见问题

stop 返回 false 时，回调一定已经执行完了吗？

不是。它最多说明回调已经不可阻止，调用方仍需用完成通道等待回调收尾。

能不能用 atomic.Bool 判断 started？

可以用原子变量记录入口，但如果调用方需要等待事件，关闭 started 通道更直接，也能避免轮询。

为什么不直接读取 ctx.Err()？

ctx.Err() 只能说明上下文是否取消以及取消原因，不能说明回调 goroutine 是否已进入或完成。

AfterFunc 的回调会和主流程并发执行吗？

会。回调在独立 goroutine 中运行；凡是共享连接、锁保护状态或临时缓冲区，都应明确开始信号和完成信号。