Go context.AfterFunc 取消回调为什么没执行：停止竞态、清理顺序与幂等处理

服务端给连接读操作加了取消保护，压测时却出现一个让人误判的现象：调用 stop() 返回了 false，清理代码像是没有执行。其实这个返回值不是“回调失败”，而是告诉你取消和回调启动已经发生了竞态，回调可能正在另一个 goroutine 里运行。真正要补上的，是对回调完成时机的同步，以及重复清理时的幂等边界。

先把 stop 的返回值读准确

context.AfterFunc(ctx, f) 会把 f 绑定到 ctx。上下文取消后，f 会在自己的 goroutine 中运行；如果上下文已经取消，回调也会尽快异步启动。返回的 stop 做的是解除关联，而不是“撤销一个已经执行的函数”。

官方文档对返回值的解释很具体：true 表示这次调用成功阻止了回调；false 表示上下文已经取消且回调可能已经启动，或者此前已经停止。两条路径都不能再假设“回调一定不会碰资源”。

连接读取场景里，竞态是怎样出现的

下面这个场景很常见：读取连接时等待客户端数据，超时后需要让读取尽快返回。回调设置一个已经到期的读截止时间，正常路径则在读取结束后解除这个回调。

stopc := make(chan struct{})
stop := context.AfterFunc(ctx, func() {
    _ = conn.SetReadDeadline(time.Now())
    close(stopc)
})

n, err := conn.Read(buf)
if !stop() {
    

如果 Read 先因为网络数据返回，stop() 可能得到 true，回调不会再运行；如果上下文先取消，回调可能已经设置截止时间，stop() 就会返回 false。此时等待 stopc 是必要的，否则下一行重置截止时间可能和回调里的设置交错。

清理顺序要围绕“谁最后写资源”来排

这个问题不只发生在连接上。文件关闭、临时目录删除、指标状态更新都可能遇到同样的时序。先列出回调和主流程分别会写什么，再决定谁负责等待。

如果两条路径都会关闭同一个文件，等待只能解决时序，不能解决重复关闭带来的错误处理问题。可以让一个路径只负责发出“需要清理”的信号，真正的关闭动作集中到一个拥有者；也可以用 sync.Once 包住幂等清理，并把关闭错误单独记录。

用显式完成信号补上 stop 不等待的空档

不要写成“stop() 返回 false 就立即释放所有相关状态”。回调尚未结束时，它可能仍在读取共享字段。简单的完成信号足以表达这个协议：

done := make(chan struct{})
stop := context.AfterFunc(ctx, func() {
    defer close(done)
    cleanupOnce.Do(func() {
        _ = conn.SetReadDeadline(time.Now())
    })
})

_, readErr := conn.Read(buf)
if !stop() {
    

示例里的关键不是某个特定同步原语，而是把“回调可能已经启动”和“回调已经完成”拆成两个事实。生产代码还应避免在回调和主流程中用相反顺序获取多把锁，否则等待清理时可能把超时问题变成死锁。

测试时要主动覆盖两条结果路径

只测上下文取消后的路径，很容易漏掉 true 分支；只测先读完的路径，又无法证明取消竞态中的资源安全。测试可以固定验证三件事：

1. 操作先完成时，stop() 返回 true，回调的副作用没有发生。
2. 上下文先取消时，回调最终发出完成信号，主流程不会提前重置共享资源。
3. 无论哪条路径，清理动作最多执行一次，重复调用不会把业务错误误报成网络错误。

竞态测试不要用一个固定的短暂等待来“碰运气”。更可靠的做法是用可控 channel 放行主流程和回调，在每个阶段都设置明确的退出条件，再用 go test -race 检查共享状态是否存在数据竞争。

常见问题

stop 返回 false 是不是说明 AfterFunc 没有执行？

不是。它说明回调可能已经启动，也可能此前已经被停止；如果需要知道回调是否完成，必须自行等待完成信号。

可以在 stop 返回 false 后直接关闭连接吗？

要看回调是否也会操作该连接。若会，先等待回调完成，再进行会改变同一资源状态的收尾动作。

为什么 defer stop() 仍然不够？

defer stop() 能解除尚未触发的关联，却不会等待已经启动的回调。涉及共享资源时，应在 defer 或显式收尾协议中补上完成同步。

小结

context.AfterFunc 的难点不在注册回调，而在理解取消与停止之间不可避免的竞态。把 true 和 false 当成两条清晰的控制路径，给已启动回调提供完成信号，再让资源清理具备幂等性，连接超时、文件收尾和状态回滚都能避免“看起来没执行”或“偶发被覆盖”的问题。