Go context.AfterFunc 怎样在取消时执行收尾逻辑

如果一个 Go 任务被取消后还需要关闭临时资源、唤醒等待者或写入收尾状态，context.AfterFunc 可以把这段逻辑挂到 Context 上。它的关键不是“取消后同步执行”，而是“取消后在独立 goroutine 中调用函数”。正常完成时要调用返回的 stop 函数；取消已经发生时，若还需要确认收尾结束，就必须自己增加完成通知。

官方地址：https://pkg.go.dev/context#AfterFunc

stop() 返回 true 只表示收尾回调还没有开始并且关联已被解除；返回 false 也不表示回调已经执行完。要等待完成，需要让回调主动关闭一个 channel 或使用其他明确的同步手段。

一、先把 AfterFunc 的触发边界说清楚

AfterFunc(ctx, f) 返回一个 func() bool。当 ctx 被取消时，标准库会在自己的 goroutine 中调用 f；如果 Context 注册前就已经取消，回调也会尽快在独立 goroutine 中启动。对同一个 Context 注册多次不会互相覆盖，每个注册都要单独管理。

package main

import "context"

func registerCleanup(ctx context.Context, closeResource func()) func() bool {
	// AfterFunc 只负责把收尾函数关联到取消信号，不替调用方管理资源所有权。
	return context.AfterFunc(ctx, func() {
		// 回调运行在独立 goroutine 中，收尾函数本身必须能安全并发执行。
		closeResource()
	})
}

这段注册代码的生产边界有两个：closeResource 不能依赖已经被其它路径关闭的对象，且不要把“回调已被调度”误写成“回调已完成”。图中的两个分组分别对应请求侧的 Context 关系和回调侧的 stop/收尾关系。

二、正常完成时要解除收尾关联

任务没有被取消而是正常返回时，调用 stop 可以解除 Context 与收尾函数的关联。最常见的写法是注册后立刻 defer stop()，这样成功返回、业务错误返回和中途退出都会走同一条解除路径。

func handle(ctx context.Context, release func()) error {
	stop := context.AfterFunc(ctx, func() {
		// 只有取消路径需要执行这里的兜底释放。
		release()
	})
	defer stop()

	// 这里执行实际任务；正常完成时 defer 会尝试阻止兜底回调。
	return doWork(ctx)
}

如果 stop 返回 true，可以理解为这次调用成功阻止了回调启动。如果返回 false，只有两种官方语义：Context 已经取消且回调已在自己的 goroutine 中启动，或者这条关联此前已经被停止。stop 不会等待 release 返回，因此不要把它当成资源释放完成信号。

三、需要完成通知时，用 done channel 补上等待

取消路径经常还要等收尾动作真正结束，例如关闭连接后才能安全复用对象、写入状态后才能返回上层。此时可以让回调在最后关闭 done，并在唯一一次调用 stop 返回 false 时等待它。

func handleWithWait(ctx context.Context, release func()) error {
	done := make(chan struct{})
	stop := context.AfterFunc(ctx, func() {
		defer close(done) // 无论 release 正常返回，等待方都能收到完成信号。
		release()
	})

	if err := doWork(ctx); err != nil {
		if !stop() {
			// false 表示回调已启动或关联已停止；本示例只在这里调用一次 stop，
			// 因而可以等待已启动的回调完成，避免把 stop 当成同步函数。
			

这里有一个容易被忽略的并发条件：同一个 stop 函数不能被多个路径随意调用后再依据返回值等待。一次调用已经返回 true 后，后续调用可能返回 false，但回调并没有启动；如果此时盲目等待 done，就可能永久阻塞。需要多个 goroutine 共同结束时，应让一个明确的所有者负责调用 stop 并协调等待。

四、发布前检查取消收尾的责任边界

可以把 AfterFunc 看成“取消触发器”，把 stop 看成“解除关联”，把 done 看成“收尾完成通知”。三者职责分开，代码就不会因为取消竞争而把资源状态判断错位。

总结

使用 context.AfterFunc 时，先注册取消后的收尾逻辑，再在正常完成路径调用 stop。看到 stop 返回 false 时，只能判断回调已经启动或关联已停止，不能据此判断收尾结束；需要等待时，让回调关闭 done channel 并由单一调用者完成协调。这样才能把取消信号、资源释放和完成状态分成清晰的生产责任边界。

相关问题

• AfterFunc 的回调为什么不能直接访问已被主流程复用的临时变量？
• 正常返回时调用 stop，为什么仍然要保留回调内部的资源保护？
• 如果多个取消回调都需要结束通知，怎样避免重复关闭同一个 channel？