上下文取消树

我在一个请求同时拉取资料、整理结果时，最容易踩到的坑不是“不会用 context.WithTimeout”，而是没有画清楚取消树：总超时应该结束整组工作，某一个分支提前结束时却不能误伤兄弟分支。理解这棵树后，取消逻辑会简单很多。

这篇只围绕一个问题展开：WithTimeout 派生多个子任务时，如何统一取消、如何让单个子任务独立退出，以及收到 Done 后怎样判断原因。结论先说：把总预算放在共同父节点，把分支差异放在各自子节点，并在每个派生边界及时调用对应的取消函数。

先把取消树画清楚

Go 的 Context 是父子关系。父 Context 取消时，所有派生出来的子 Context 都会被取消；子 Context 自己取消时，只影响它和它的后代，不会反向取消父节点，也不会直接取消兄弟节点。因此，多任务场景通常可以画成“请求根节点 → 总超时节点 → 多个子任务节点”。

例如，资料读取和结果整理都从同一个总超时节点派生。总超时一到，两个分支都能观察到自己的 Done 被关闭；如果只是读取分支主动取消，整理分支仍然拥有自己的上下文。这里的“传播”是取消信号的父子语义，不代表图中存在固定的执行先后。

总超时统一收口

总超时应该只创建一次，并把返回的上下文传给所有需要受这次请求约束的子任务。下面的例子使用两个 goroutine 表达关系，重点是派生位置和取消函数的归属。

package main

import (
	"context"
	"fmt"
	"time"
)

func runRequest(parent context.Context) {
	// 总超时是这组子任务共享的预算，调用方结束前要释放定时器。
	requestCtx, cancelRequest := context.WithTimeout(parent, 800*time.Millisecond)
	defer cancelRequest()

	// 两个分支共享 requestCtx，所以父级取消会同时通知它们。
	go func() {
		if err := readProfile(requestCtx); err != nil {
			fmt.Println("读取分支结束：", err)
		}
	}()
	go func() {
		if err := buildSummary(requestCtx); err != nil {
			fmt.Println("整理分支结束：", err)
		}
	}()
}

func readProfile(ctx context.Context) error {
	select {
	case 

实际项目中，子函数还应把 ctx 继续传给支持 Context 的数据库、HTTP 或文件操作。只在 goroutine 外层监听 Done，而底层调用完全不接收上下文，取消信号就无法真正停止那段工作。

子任务单独退出

“统一取消”不等于“所有分支永远共用一个取消函数”。如果读取分支发现自己的结果已经没有价值，可以从总超时节点派生一个更窄的 WithCancel，并只调用这一支的 cancelRead。这不会让父级取消，也不会让整理分支收到同一个子级的主动取消。

func runBranches(parent context.Context) {
	// 父级负责整组超时，子级负责某个分支的提前收尾。
	groupCtx, cancelGroup := context.WithTimeout(parent, time.Second)
	defer cancelGroup()

	readCtx, cancelRead := context.WithCancel(groupCtx)
	defer cancelRead()

	go func() {
		if err := readProfile(readCtx); err != nil {
			// 这里只会收敛读取分支自己的结果。
			fmt.Println("读取分支：", err)
		}
	}()

	go func() {
		if err := buildSummary(groupCtx); err != nil {
			// 整理分支仍然观察共同父级，而不是 readCtx。
			fmt.Println("整理分支：", err)
		}
	}()

	// 业务条件满足时只结束读取分支，兄弟分支不受影响。
	cancelRead()
}

这里的关键不是把 WithCancel 机械地套在每个函数外面，而是先决定取消边界：整组任务的预算由 groupCtx 管，单分支的生命周期由 readCtx 管。若所有分支都直接使用同一个子 Context，任何一支调用它的 CancelFunc 都会把其他分支一起带走。

从 Done 和 Err 判断结果

Done 只告诉你取消信号已经到达，真正的原因要通过 Err 读取。常见的两类结果是 context.DeadlineExceeded 和 context.Canceled：前者通常表示截止时间先到，后者通常表示某个取消函数或上游主动结束。

func waitResult(ctx context.Context) error {
	select {
	case 

父级 WithTimeout 触发时，子级通常会继承 DeadlineExceeded；如果某个子级自己的 CancelFunc 先被调用，它通常会观察到 Canceled。不要只按“是否有错误”做重试或报警，至少要保留这两个原因的区分。

把资源释放放在边界

每一次 WithTimeout、WithDeadline 或 WithCancel 都会返回一个取消函数。官方文档建议在对应操作完成后尽快调用它：对计时上下文来说，这会停止关联定时器；对取消树来说，也会解除父节点对该子节点的引用。最稳妥的做法是派生后立刻写 defer cancel()，再根据业务条件提前调用。

可以用下面这张表快速决定取消边界：

容易混淆的三个边界

第一，Context 不是“杀死 goroutine”的按钮。它只能发出取消信号，业务函数必须在阻塞点选择 ctx.Done()，或者把上下文交给支持取消的下层 API。

第二，子上下文的取消不会向上冒泡。如果你需要“一个分支失败就结束整组”，需要把这个业务决策显式放在共同父级的控制逻辑里，而不是期待某个子级的 cancel 自动取消父级。

第三，超时是最晚的边界，不是所有分支的独立 SLA。如果某个分支必须更快结束，可以在共同父级下再派生更短的 WithTimeout；但它的截止时间只能更早地约束该分支，不能延长已经更早到期的父级预算。

结语

“上下文取消树”的实用画法只有一句话：共同的总预算放在共同父节点，分支的局部收尾放在分支子节点。总超时负责统一收口，单分支 WithCancel 负责隔离提前退出，Done 与 Err 负责把结束信号翻译成可处理的原因，最后别忘了释放每一层的 CancelFunc。

如果你继续扩展这套结构，优先检查三件事：底层调用是否真的接收并响应 Context、每个派生节点是否都有明确的取消责任、以及重试和日志是否区分 DeadlineExceeded 与 Canceled。这三点比继续增加 goroutine 数量更能决定取消逻辑是否可维护。