Go context.AfterFunc 怎么在取消后释放外部资源

我在给请求处理器补取消逻辑时，最容易误判的是：调用 stop() 返回，并不等于外部资源已经释放。context.AfterFunc 会在取消后用独立 goroutine 执行回调；如果 stop() 返回 false，调用方还要等待回调真正结束。稳定的做法是让释放动作幂等，再用完成信号收敛两条路径。

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

为什么取消后还可能泄漏外部资源

AfterFunc 适合把“取消时要做的动作”挂到 Context 上，例如打断阻塞读、关闭临时连接或回收一个租约。但它不是同步清理器：回调和业务函数可能同时访问同一个资源，stop() 也不会等待回调结束。

这会形成一个很具体的竞态。业务函数正常返回后调用 stop()，如果此时取消信号已经触发，返回值可能是 false；而回调仍在释放资源。若调用方看到返回就立刻复用连接，便可能与清理动作交叉。反过来，如果两边都直接 Close，又会出现重复释放或二次归还池的问题。

用 stop 判断回调是否已经接管清理

先把资源释放封装成幂等动作，再把回调完成状态单独表达出来。下面的代码不依赖某一种资源类型；真实项目里可以把 release 换成连接关闭、文件删除或租约归还。

type resource struct {
	once sync.Once
	release func() error
}

func (r *resource) closeOnce() {
	r.once.Do(func() {
		// 释放动作可能由正常返回和取消回调竞争，只允许真正执行一次。
		_ = r.release()
	})
}

func useResource(ctx context.Context, r *resource) error {
	done := make(chan struct{})
	stop := context.AfterFunc(ctx, func() {
		defer close(done)
		// 取消后由回调接管资源释放，并通知调用方可以继续收尾。
		r.closeOnce()
	})

	// 这里执行使用 r 的业务操作；示例省略具体 I/O。
	if err := doWork(ctx, r); err != nil {
		if !stop() {
			// 回调可能正在释放资源，返回前必须等它完成。
			

这里的关键不是把 stop() 当成关闭函数，而是依据返回值划分所有权：true 时回调不会再运行，调用方负责释放；false 时回调可能已启动，必须等 done。sync.Once 让极窄的竞争窗口也不会二次释放。

用完成信号把清理边界收紧

done 必须在回调最后关闭，而不是刚进入回调就关闭。否则调用方可能收到信号后立即使用仍在清理的资源。回调内部如果还有多个释放动作，应让它们全部完成后再执行 close(done)。

如果释放动作本身会返回错误，还要提前决定错误归属：取消回调通常只能记录或上报，正常返回路径则可以把业务错误返回给上层。不要为了把错误塞回调用方而在回调里直接写一个无人接收的 channel；这会让取消时序变得更脆弱。

常见问题

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

只要后续代码可能访问、复用或销毁同一资源，就应该等待。官方语义明确说 stop 不等待回调完成；只有当资源完全独立且调用方不再关心其生命周期时，才可以不等待。

为什么还要使用 sync.Once？

它不是用来替代 stop() 的，而是保护释放动作。正常返回与取消刚好并发时，两条路径都可能抵达清理函数，幂等保护能把关闭、删除或归还动作收敛成一次。

AfterFunc 适合承载所有清理工作吗？

不适合。它适合取消触发的、小范围且可协调的动作。复杂清理应由明确的生命周期管理器负责，AfterFunc 只发送取消信号或唤醒阻塞操作，避免把大量业务逻辑藏进异步回调。

排查这类问题时，我会先记录 stop() 的返回值，再确认 done 是否覆盖了回调末尾，最后检查释放函数是否幂等。三点都满足，取消与正常返回的资源边界才算真正闭合。