Go context.AfterFunc 取消回调为什么仍可能执行：停止竞态与资源回收边界

服务收到取消信号后，日志里却偶尔还能看到清理回调；这通常不是 context.AfterFunc 失效，而是把“阻止回调启动”和“等待回调结束”当成了一件事。Stop 返回 false 时，回调可能已经开始，调用方必须另行等待它完成。

先把取消信号和回调任务分开看

AfterFunc(ctx, f) 监听的是上下文完成事件。上下文结束后，标准库会安排 f 异步运行；它不是在调用 cancel() 的那个 goroutine 里同步执行。

这意味着链路里至少有三份状态：请求是否已取消、回调是否已启动、回调是否已完成。排查问题时只记录第一份状态，最容易得到“已经取消，为什么还在清理”的错觉。

用最小示例观察 Stop 的两个结果

先让上下文保持有效，直接调用停止函数，比较容易看到阻止成功的路径：

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

stopped := context.AfterFunc(ctx, func() {
    log.Println("cleanup started")
})

if stopped() {
    log.Println("cleanup was prevented")
}

这里回调还没有被触发，停止函数返回 true。但如果先调用 cancel()，调度器可能已经把回调启动，随后再调用停止函数就会返回 false。

ctx, cancel := context.WithCancel(context.Background())
done := make(chan struct{})

stop := context.AfterFunc(ctx, func() {
    defer close(done)
    log.Println("cleanup started")
    time.Sleep(20 * time.Millisecond)
})

cancel()
if !stop() {
    log.Println("cleanup already started or is about to run")
}

done 才是这段示例的完成信号。不要把 Stop 的返回值当作清理结束通知，否则关闭连接、删除租约等操作可能与下一次请求重叠。

回调中的资源应该怎样校验和收尾

把资源句柄的生命周期单独列出来会更稳：创建阶段保存句柄，回调启动时先检查它是否仍属于当前请求，收尾阶段使用一次性保护。下面的写法适合关闭一个只应释放一次的资源：

var once sync.Once
release := func() {
    once.Do(func() {
        _ = conn.Close()
        log.Println("connection released")
    })
}

done := make(chan struct{})
stop := context.AfterFunc(ctx, func() {
    defer close(done)
    release()
})

if stop() {
    release()
}

示例里有一个细节：若 stop() 返回 true，回调不会再替你关闭连接，所以调用方要完成主动收尾；若返回 false，回调可能负责收尾，调用方仍应等待 done。sync.Once 把两条路径合并成安全的幂等动作。

停止竞态怎样做可复现验证

不要只靠偶发日志判断。可以用两个通道把“回调已启动”和“允许回调结束”拆开，再分别记录 stop 返回值：

started := make(chan struct{})
finish := make(chan struct{})
done := make(chan struct{})

stop := context.AfterFunc(ctx, func() {
    close(started)
    

这个实验重点不是固定某个调度顺序，而是让每个状态都有证据：收到取消、回调启动、停止结果、回调完成。线上日志也建议保留同样的四个事件字段，避免把异步行为压缩成一句“已取消”。

常见问题

Stop 返回 false 是否代表回调已经执行完？

不代表。它只说明回调已经开始或停止动作与启动发生了竞态；要确认结束，必须等待回调自己的完成通知。

回调里能不能直接复用请求上下文？

可以读取上下文状态，但不要把“上下文已取消”当成资源已经释放。回调需要的资源引用和完成信号应由调用方明确管理。

为什么要给关闭动作加 sync.Once？

因为停止成功和回调已启动是两条互斥但都可能触发收尾的路径。一次性保护能避免重复关闭、重复删除或重复提交释放记录。

把判断落到三条检查上

使用 context.AfterFunc 时，先问“回调是否可能已启动”，再问“谁负责最终释放”，最后问“我用什么信号证明它完成”。只要这三项写在代码旁边，Stop 就只是一个竞态结果，而不会被误当成完整的生命周期协议。