Go context 怎样合并多个取消来源

在一个 HTTP 请求里，工作可能同时受到三种信号影响：客户端断开、业务超时、服务主动停止。若每个函数都单独接收并监听这些信号，退出分支很快会变成重复代码。更稳妥的做法是先把多个来源合并成一个派生 context，让下游只依赖一个 Done()。

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

Go 标准库没有提供“把任意多个 Context 直接相加”的通用构造器，但可以用一个可取消子 context 作为汇合点：第一个来源取消时调用统一的 cancel，所有下游只监听这个子 context。

先把“多个来源”变成一个取消出口

合并的关键不是把多个 Done() channel 拼成一个 channel，而是定义清楚谁拥有最终的取消权。下面的例子把 requestCtx 作为父 context，把 stopCtx 作为第二个来源：请求取消会沿父子关系传播，第二个来源则由 AfterFunc 转发到同一个 cancel。

这里选择 WithCancelCause，是因为取消之后通常还要回答“为什么退出”。如果只需要一个布尔意义上的停止信号，也可以将它换成 WithCancel。

package main

import (
	"context"
	"errors"
	"fmt"
)

// mergeCancel 把第二个取消来源接到第一个来源派生出的子 context 上。
func mergeCancel(parent, extra context.Context) (context.Context, context.CancelFunc) {
	merged, cancel := context.WithCancelCause(parent)

	// extra 取消时，把它的原因转发给 merged；AfterFunc 返回停止关联的函数。
	stop := context.AfterFunc(extra, func() {
		cancel(context.Cause(extra))
	})

	return merged, func() {
		// 先停止尚未触发的回调，再让调用方主动结束 merged。
		stop()
		cancel(context.Canceled)
	}
}

func main() {
	requestCtx := context.Background()
	stopCtx, stop := context.WithCancelCause(context.Background())
	defer stop(errors.New("service stopping"))

	merged, cancel := mergeCancel(requestCtx, stopCtx)
	defer cancel()
	

为什么清理函数必须同时停止回调和取消子 context

AfterFunc 的回调运行在自己的 goroutine 中。返回的 stop 只负责解除关联，不等待一个已经启动的回调完成；所以统一的清理函数需要具备幂等性，并在所有正常返回路径上调用。

上例中的 cancel 可以被多个 goroutine 调用，第一次调用决定取消状态，后续调用不会重复执行取消动作。stop() 则避免工作提前结束时，第二个来源仍然保留一条不再需要的回调关系。两者承担的职责不同，不能只保留其中一个。

让下游只监听 merged，避免 goroutine 留在半路

合并完成后，工作函数不需要知道取消来自哪个上游，只要在阻塞点同时监听 merged.Done()。如果还要向输出 channel 写数据，也要把写入放进同一个 select，否则接收方退出后，发送方仍可能卡住。

func consume(ctx context.Context, out chan

要注意，取消函数不会等待业务 goroutine 停止。下游是否真正退出，取决于它是否在自己的阻塞点检查 Done()，以及它依赖的 I/O 是否支持 context。合并 context 解决的是取消传播，不会强行中断一个不响应 context 的外部调用。

旧版本降级与退出原因判断

AfterFunc 从 Go 1.21 起提供。如果项目需要兼容更旧的 Go 版本，可以用一个专用 goroutine 监听第二个来源，再调用统一 cancel；这种写法要在清理时关闭一个 done channel，防止监听 goroutine 永远等待。

如果只需要判断是否超时，使用 errors.Is(err, context.DeadlineExceeded)；如果需要区分业务原因，使用 context.Cause。先检查 ctx.Err() 能确认已经取消，但它只会给出 context.Canceled 或 context.DeadlineExceeded 这类标准结果。

最后记住三条边界：

• 每次创建带取消、截止时间或超时的 context，都在责任边界内调用对应的 cancel。
• 合并函数只负责传播取消，不要借它传递可选业务参数或隐藏共享状态。
• 下游函数要在读取、发送和外部调用等阻塞位置响应同一个 merged context。

相关问题

多个来源同时取消时哪个原因会留下？

Context 的首次取消会确定 cause。并发情况下不要依赖来源之间的先后顺序；如果业务需要稳定优先级，应在上层显式定义并记录来源。

为什么调用 cancel 后 goroutine 还没马上结束？

CancelFunc 不等待工作停止，Done channel 的关闭也可能异步发生。工作函数必须主动检查 Done，并对外部 I/O 使用支持 context 的 API。