Go Context取消信号机制深度解析：从原理到工程实践

做 Go 开发，有几件事你迟早要正面撞上：goroutine 泄漏、超时控制失效、服务一重启整个依赖链跟着雪崩。这三件事背后的元凶往往指向同一个——你根本没掌握 Context 的取消信号机制。我见过不少项目，context.Background()从头传到底，WithCancel返回的 cancel 函数随手丢一边，然后线上出现 goroutine 数量只增不减，查半天才发现下游调用全在傻等一个永远不会回来的响应。

这篇文章不打算把 Context 的 API 文档复述一遍，我要做的是把取消信号的传播链路彻底拆开来看：cancel 函数被调用后，子 context 是怎么知道的？为什么父 context 取消，所有子 context 都会收到信号？WithTimeout和WithDeadline在底层到底有什么不同？哪些用法会在不知不觉中埋下泄漏的雷？全程用可复现的代码示例说话，你照着跑一遍就能看到效果，看完可以直接把这个机制用到自己的项目里做超时控制和优雅退出。

1. 取消信号机制的设计思路：为什么 Go 需要它

先打个比方。你开了一家餐厅，后厨有十个灶台，每个灶台对应一个 goroutine 在处理订单。有一天老板决定提前打烊，你的第一反应是告诉所有厨师“今天的单子都不做了”。如果这十个灶台之间没有任何沟通渠道，你就得挨个跑到每个灶台前喊一句，跑慢了可能某个厨师已经开始炸东西了，白白浪费食材。

Context 就是这条沟通渠道。它的核心职责不是传参数，而是让父级 goroutine 有能力通知子级 goroutine：“别干了，收工”。这就是取消信号机制存在的根本理由。具体到 Go 语言里，一个用户请求往往会派生出几十个甚至上百个 goroutine 去处理不同的子任务，比如同时查数据库、调外部 API、写日志。如果请求中途客户端断开了，或者服务端检测到处理超时了，你总不能继续让这些 goroutine 继续跑下去——它们大概率拿不到结果，只会白白占着内存和 CPU。

我最早接触 Context 是在做一个网关项目，每个请求进来要并发调三个下游服务。初期版本没做超时控制，某天一个下游服务响应变慢，从 200ms 涨到 5 秒，结果网关的 goroutine 数量瞬间冲到几十万，内存告警直接打爆。那时候才意识到，单个 goroutine 卡住不可怕，可怕的是它卡住后没有任何机制可以唤醒它、终止它。Context 就是为解决这类问题而生的：把取消的决定权从“被打断的 goroutine 自己手里”转移到“发起任务的父级手里”，由父级统一发号施令。

再往深处想一层，取消信号机制不只是一个 bool 变量，它更像是一个层级组织里的命令链。一个请求的生命周期里，context.Background()在最顶层，往下一层通过WithCancel、WithTimeout派生出子 context，每个子 context 还可以继续派生。这棵树上任何一个节点的取消信号被触发，都会向它的所有子孙节点广播。这种树状传播设计恰好匹配了真实业务里的依赖关系：请求入口是根，每个子任务是从根分叉出去的枝干，枝干下面还有更细的分工。

这种设计带来的好处很直接：你不用在业务代码里维护一份全局的“哪些 goroutine 需要取消”的清单，context 树本身就替你管理好了依赖关系，你只需要确保每个 goroutine 都能收到它应该听到的那个取消信号。

2. 核心机制深入拆解：cancelCtx 与传播链路

2.1 Context 接口与 done channel 的底层逻辑

先看看 context 包底层的核心定义：

type Context interface { Deadline() (deadline time.Time, ok bool) Done() <-chan struct{} Err() error Value(key any) any }

这接口上四个方法每个都有明确职责：Deadline报告这个 context 有没有设置截止时间；Done返回一个 channel，这个 channel 在 context 被取消时会关闭；Err告诉你取消的原因；Value则是传递请求级元数据用的。

取消机制的关键就在Done()返回的 channel 上。channel 是 Go 语言天然的通知工具，父级取消时只需要close(done)，所有在select里等待这个 channel 的 goroutine 会立即收到零值通知。这里有个技术细节值得注意：channel 的关闭操作是广播式的，所有监听者都会同时被唤醒，不需要像 mutex 那样逐个通知。这就是为什么 Context 能高效地同时取消上百个 goroutine，底层本质上就是在玩 channel 的关闭广播。

具体到源码实现，cancelCtx结构体长这样：

type cancelCtx struct { Context mu sync.Mutex done atomic.Value children map[canceler]struct{} err error }

每个cancelCtx都持有两个关键字段：done是那颗关闭后通知所有人的信号弹，children是它直属的子 context 集合。当父 context 被取消时，它要做的就是：关闭自己的 done channel，遍历 children 里每个子 context 调用它们的 cancel 方法。这样取消信号就像多米诺骨牌一样，一级一级往下传。

2.2 propagateCancel：父子取消信号的接棒过程

有了父子结构，下一个问题就是：子 context 是怎么知道自己的“上级”是谁的？答案在一个叫propagateCancel的内部函数里。

func propagateCancel(parent Context, child canceler) { done := parent.Done() if done == nil { return // 父 context 不可取消，子 context 也就无从传播 } select { case <-done: // 父 context 已经取消了，子 context 立即取消 child.cancel(false, parent.Err()) return default: } // 若父 context 实现了 canceler 接口，注册到它的 children 中 if p, ok := parentCancelCtx(parent); ok { p.mu.Lock() if p.err != nil { child.cancel(false, p.err) } else { p.children[child] = struct{}{} } p.mu.Unlock() } }

这个过程可以类比成入职登记：新员工（子 context）入职时要告诉直属上级“我归你管”，上级把名字记在花名册（children map）上。上级离职时，会按花名册逐个通知“你们都别干了”。如果子 context 入职时发现上级已经离职了，那就当场走人——对应代码里的parent.Err()非空时立即 cancel。

这里有个容易被忽略的边界情况：如果父 context 是一个自定义实现的、不能被类型断言为canceler的类型，那就没法注册到 children 里。此时propagateCancel会启动一个 goroutine 监听父 context 的 done channel，父级取消时手动触发子取消。这种兜底方案保证了传播逻辑在任意实现下都能工作，代价是额外增加了一个 goroutine 的开销。实际项目中这种场景很少见，但你如果看到某些实现里 goroutine 数量对不上，这算一个冷门来源。

2.3 cancel 函数背后的 close 与递归调用

接下来是最核心的一部分：cancel 函数被调用时到底干了什么。

func (c *cancelCtx) cancel(removeFromParent bool, err error) { if err == nil { panic("context: internal error: missing cancel error") } c.mu.Lock() if c.err != nil { c.mu.Unlock() return // 已经取消过了，幂等处理 } c.err = err d, _ := c.done.Load().(chan struct{}) close(d) for child := range c.children { child.cancel(false, err) } c.children = nil c.mu.Unlock() if removeFromParent { removeChild(c.Context, c) } }

我拆开来讲。第一步加锁，避免并发环境下多个 goroutine 同时触发 cancel 导致重复关闭 channel。第二步设置 err 字段，标记这个 context 已经被取消，同时这也是Err()方法返回值的来源。第三步关闭 done channel，这一步完成后，所有在select里等待这个 channel 的 goroutine 都会收到通知。第四步遍历 children 集合，一个一个取消它们。

整个流程里最关键的设计是幂等性：cancel 函数可以多次调用，但从第二次开始因为c.err已经非空，会直接 return。这意味着你不用在业务代码里小心翼翼地判断“这个 context 是不是已经被取消了”，放心大胆地调用 cancel 不会出问题。还有一个细节是removeFromParent参数，它对根 context 调用时是 false，表示根节点不需要从谁的 children 里摘除；对子 context 调用时是 true，需要从父节点里把自己摘掉，避免父节点已经取消了却还保留着这个引用造成内存泄漏。

2.4 WithTimeout 与 WithDeadline 的定时取消原理

WithTimeout和WithDeadline是一对孪生兄弟，底层用的都是timerCtx。区别只在于传入参数：一个传时长（比如 3 秒），一个传绝对时间点（比如2025-01-01 00:00:00）。WithTimeout内部本质上就是调用了WithDeadline，帮你把当前时间加上时长换算成了截止时间。

func WithTimeout(parent Context, timeout time.Duration) (Context, CancelFunc) { return WithDeadline(parent, time.Now().Add(timeout)) }

WithDeadline的实现会创建 timer，在截止时间到达时自动触发 cancel：

func WithDeadline(parent Context, d time.Time) (Context, CancelFunc) { if cur, ok := parent.Deadline(); ok && cur.Before(d) { return WithCancel(parent) } c := &timerCtx{ cancelCtx: newCancelCtx(parent), deadline: d, } propagateCancel(parent, c) dur := time.Until(d) if dur <= 0 { c.cancel(true, DeadlineExceeded) return c, func() { c.cancel(false, Canceled) } } c.mu.Lock() defer c.mu.Unlock() if c.err == nil { c.timer = time.AfterFunc(dur, func() { c.cancel(true, DeadlineExceeded) }) } return c, func() { c.cancel(true, Canceled) } }

这里有个性能方面的巧思：如果用 WithCancel 创建的 context，父 context 提前取消了，子 context 会通过传播链收到信号；如果用 WithDeadline 创建，且父 context 的 deadline 比子 context 更早，那么子 context 根本没有必要启动自己的 timer，直接复用父级的 deadline 触发时机就够了。判断条件就是cur.Before(d)，一旦成立就降级为 WithCancel 行为。这个优化省掉了大量 timer 资源，尤其在高频创建短暂超时 context 的场景下很值得关注。

3. 实操环节：四个标准取消场景的完整实现

理论说了这么多，接下来进入实战环节。我会把日常开发里最常见的四个取消场景挨个过一遍，每个场景都配有可以直接复制到项目里的代码片段。

3.1 场景一：手动取消——用 cancel 函数主动叫停

最基础的场景：你启动了一个 goroutine 去做耗时任务，任务过程中随时可能因为业务逻辑需要叫停。

func worker(ctx context.Context) { for { select { case <-ctx.Done(): fmt.Println("worker 收到取消信号，退出") return default: fmt.Println("worker 正在干活...") time.Sleep(1 * time.Second) } } } func main() { ctx, cancel := context.WithCancel(context.Background()) go worker(ctx) time.Sleep(3 * time.Second) cancel() time.Sleep(1 * time.Second) fmt.Println("主函数结束") }

运行后你会看到 worker 打印三次“正在干活”，然后收到取消信号退出。这个模式的核心有两个点：一是 worker 内部必须通过select主动检查ctx.Done()，如果不检查，取消信号发了也白发；二是cancel()要放在主函数的调用路径上，确保任务完成或不再需要时及时触发。

另一个常见的坑是忘记调用cancel()。我在 code review 里见过太多这种写法：ctx, _ := context.WithCancel(...)，然后直接把父 context 丢给下游函数使用。这意味着这个 context 及其所有子 context 的 done channel 永远不会被主动关闭，只能等父 context 被取消或者进程结束。如果下游函数内部启动了长生命周期 goroutine，这些 goroutine 就永远失去了被主动终止的机会，泄漏就这样产生了。

正确姿势是：WithCancel拿到的 cancel 函数，一定要通过defer cancel()或显式调用保证它一定被执行，覆盖率要像defer关闭文件句柄一样成为肌肉记忆。

3.2 场景二：超时控制——WithTimeout 拦截慢请求

真实项目里最常用的场景，没有之一。一个 HTTP 接口请求进来，调下游服务最多等 3 秒，超时就不再等待，直接返回失败。

func callDownstream(ctx context.Context) (string, error) { select { case <-time.After(5 * time.Second): return "下游响应", nil case <-ctx.Done(): return "", ctx.Err() } } func handler(ctx context.Context) { ctx, cancel := context.WithTimeout(ctx, 3*time.Second) defer cancel() resp, err := callDownstream(ctx) if err != nil { fmt.Println("请求失败:", err) return } fmt.Println("请求成功:", resp) }

这段代码里有个非常实用的经验：下游函数内部不要使用time.After这种硬编码等待。始终应该用select同时监听“业务完成”和“context 取消”两个事件，谁先到就响应谁。这样才能确保上层超时后，下层能够立即停止等待，而不是继续傻等到 5 秒结束。

ctx.Err()返回的值也值得说清楚：超时触发的取消返回DeadlineExceeded，手动调用 cancel 触发的取消返回Canceled。这两个错误码在链路追踪和调用方决策时是有区别的——前者表示“任务来不及完成”，后者表示“任务被主动放弃”，处理策略应当不同。

3.3 场景三：Deadline 统一截止——多个子任务共用一个死线

假设一个接口需要并发请求两个下游服务，我希望整体耗时最多 2 秒。这时候不能给每个下游单独设置 2 秒超时，因为串行积累下来总体可能超过 2 秒。正解是给两个 goroutine 共享同一个带 deadline 的 context。

func handler(ctx context.Context) { ctx, cancel := context.WithTimeout(ctx, 2*time.Second) defer cancel() var wg sync.WaitGroup ch := make(chan string, 2) wg.Add(2) go func() { defer wg.Done() ch <- callServiceA(ctx) }() go func() { defer wg.Done() ch <- callServiceB(ctx) }() wg.Wait() close(ch) for resp := range ch { fmt.Println("结果:", resp) } } func callServiceA(ctx context.Context) string { time.Sleep(1 * time.Second) return "A 完成" } func callServiceB(ctx context.Context) string { time.Sleep(3 * time.Second) return "B 完成" }

这个场景真正的精髓在于：B 服务虽然耗时 3 秒，但 deadline 是 2 秒，B 内部的select监听 ctx.Done 后会在第 2 秒触发取消，不会白白等满 3 秒。两个 goroutine 的总耗时严格控制在 2 秒左右。如果我把超时分别传给两个服务，总耗时可能叠加到 4 秒，完全达不到接口响应时间的要求。

这种“共用一个 deadline”的模式在聚合查询、批量 RPC、扇出任务里非常常见，掌握后能显著提升你对整体链路耗时的把控能力。

3.4 场景四：WithValue 传参——注意只传请求级元数据

WithValue严格来说跟取消信号机制无关，它解决的是另一个问题：在不侵入函数签名的情况下，把请求级的元数据传给下游函数。典型使用场景是传递 trace ID、用户 ID、客户端 IP 这些每个请求都可能变化的信息。

type traceIDKey struct{} func withTraceID(ctx context.Context, traceID string) context.Context { return context.WithValue(ctx, traceIDKey{}, traceID) } func getTraceID(ctx context.Context) string { if v, ok := ctx.Value(traceIDKey{}).(string); ok { return v } return "" }

官方文档和社区共识都明确建议：Value的 key 不要用内置的 string 或 int 类型，因为不同包可能用字符串"user"做 key，容易碰撞。应该自定义一个私有结构体类型作为 key，保证类型安全。比如上面代码里的traceIDKey，它本身是空结构体，但因为是私有类型，外部包没法构造出同样的 key 来读取数据。

另外一点经验：WithValue只适合放“跟当前请求生命周期绑定、只读不改、每个层级都要用”的数据，千万不要用它来替代函数参数传递核心业务逻辑依赖。如果某个值只在某一个下游函数里用一次，直接传参数就好，没必要塞进 context 里增加隐式耦合。

4. 源码级细节补充：context 树的构建与判断技巧

4.1 从 Context 三件套理解树状结构的完整形态

context.Background()、context.TODO()、context.WithValue()这三个放在一起说。前两个返回的是不可取消的emptyCtx类型实例，它们的Done()返回 nil channel，Deadline()返回(time.Time{}, false)，Err()返回 nil。它们的作用是作为整棵 context 树的根节点。

Background()是线上服务创建根 context 的标准入口，语义是“这个请求没有父级，从零开始”。TODO()则是一个过渡标记，语义是“这里暂时还没有确定用什么 context，先占个位”。我建议只在开发调试时用TODO()，生产代码里如果出现了它，基本可以断定是没想清楚就写了。

WithValue创建的是valueCtx类型，它跟cancelCtx的树结构是相互独立的。WithValue会生成一个只有 Value 方法被实现的 context 包装层，取消传播不经过它。所以理论上你可以给同一个 context 叠加多个WithValue层，每一层都只负责保存一个 key-value，读取时会沿包装链逐层向上查找。这也是为什么说Value查找是 O(n) 复杂度的，使用时要保持克制。

4.2 判断 context 是否被取消的三个关键信号位

• ctx.Done()不为 nil：说明这个 context 是可取消的，应该建立监听
• ctx.Err()非 nil：说明这个 context 已经被取消，且能拿到取消原因
• ctx.Deadline()的第二返回值 ok 为 true：说明设置了截止时间

监听逻辑的标准写法是：

select { case <-ctx.Done(): // 取消善后逻辑：清理资源、返回错误 return nil, ctx.Err() default: // 正常处理路径 }

另一种常见写法是把<-ctx.Done()放在一个独立 goroutine 里做善后处理，主流程继续往下走。无论哪种写法，记住一个原则：不要阻塞在只会被取消信号唤醒的等待上。如果你发起一个网络请求，而请求库内部没有监听 ctx.Done，那么即使 context 取消了，这个请求也会继续跑完，只是调用方早就不等结果了——资源照样浪费。

4.3 errgroup 的取消传播：并发编排的天然搭档

errgroup库是官方扩展包golang.org/x/sync/errgroup的一部分，它本质上封装了WithCancel的传播逻辑。

func main() { g, ctx := errgroup.WithContext(context.Background()) g.Go(func() error { select { case <-time.After(2 * time.Second): return nil case <-ctx.Done(): return ctx.Err() } }) g.Go(func() error { return errors.New("第二个任务直接失败") }) if err := g.Wait(); err != nil { fmt.Println("任务失败:", err) } }

运行行为很有代表性：第二个任务立即返回错误，errgroup 内部检测到错误后会调用cancel()，于是第一个任务也收到取消信号提前退出。这个机制非常适合做扇出任务，任何一个子任务失败时，整体链路不再等待其他子任务，直接进入失败处理状态。

我用 errgroup 踩过一次坑：它默认只取消其他 goroutine，但不会等待它们全部退出就返回了Wait()结果。如果你的善后逻辑依赖所有 goroutine 都结束，需要自己在子任务内部加sync.WaitGroup。另外 errgroup 的取消是基于 WithCancel 的，不是 WithTimeout，所以如果要整体超时，你还需要再在外层包一层context.WithTimeout。

4.4 携带取消信息跨进程：gRPC 与 HTTP 的传播实践

单一进程内，context 传参非常直接。但微服务架构下，A 服务调用 B 服务时，A 的超时和取消信息怎么传给 B？gRPC 协议里对这个问题有原生支持：context.WithTimeout创建的超时信息，在发起 gRPC 请求时会被编码进 HTTP/2 的 metadata 中，对端解码后会自动构建出带同样 deadline 的 context。

HTTP 服务之间的传播则是另一套逻辑。Go 标准库的http.Request本身就带Context()方法，服务端可以通过r.Context()拿到客户端请求的上下文。当客户端断连时，服务端的r.Context()会自动被取消，Done()channel 会收到通知，服务端就能停止处理这个请求。这些机制都说明，Context 的取消信号机制不仅限于单个进程，它是 Go 生态里贯穿网络通信层的基础能力。

我建议你在设计自己的 RPC 或者消息队列消费逻辑时，也沿用这个思路：消息体里带上 trace ID 和 deadline，消费者拿到后主动构造 context，把取消能力往下游传播。这样整条链路的超时控制才是闭环的，不会出现“网关超时了，但下游服务还在默默干活”的割裂状态。

5. 高并发场景下的典型问题与排查实录

5.1 线上事故：goroutine 数量只增不减

我参与过的一个广告投放系统，上线后两周内存曲线一路爬升，goroutine 数量稳定在百万级别。排查时先用pprof抓 goroutine 栈，发现大量 goroutine 阻塞在https://google.golang.org/grpc.(*ClientConn).Invoke的等待响应上。

进一步看代码，问题出在调用下游 RPC 时没有设置超时：ctx := context.Background()直接传给 grpc 调用，下游服务响应慢，grpc 客户端就无限期等待。客户端用户早已断连，但 goroutine 完全不知情。

修复方案很简单：在调用入口统一加上context.WithTimeout(ctx, 2*time.Second)，同时让 grpc 客户端通过grpc.WithContextDialer正确感知 context 取消。上线后 goroutine 数量立刻稳定在几千级别。这次事故让我彻底明白了：Context 的取消机制不是可选的代码风格，而是 Go 并发程序的氧气。

5.2 排查手段：通过 pprof 快速定位阻塞点

这里分享具体的排查操作。程序运行时开启 pprof 端口：

import _ "net/http/pprof" func main() { go func() { http.ListenAndServe("localhost:6060", nil) }() // 业务代码 }

然后执行：

go tool pprof http://localhost:6060/debug/pprof/goroutine

进入交互界面后，输入top查看 goroutine 样本占比，再输入traces查看具体函数调用栈，重点看哪些函数长时间阻塞在 channel 等待上。绝大多数泄露场景下，阻塞位置都指向select { case <-ctx.Done(): ... default: ... }里没有 default 分支的等待，或者网络库内部没有正确处理 context 取消。

还有个不算技巧的技巧：在代码里加一个定时的 goroutine 数采样日志。runtime.NumGoroutine()只要一行代码，但能帮你在问题发生前就发现趋势异常。我在生产环境里会记录每分钟的 goroutine 均值、峰值和 p99，配合告警规则，能在服务内存被打爆之前就收到预警。

5.3 常见误用模式：cancel 函数未调用的三种表现

先说最典型的一种：WithCancel返回的 cancel 没被调用。表现是 context 永远处于活跃状态，所有监听Done()的 goroutine 永远不会收到信号。比如你写个定时任务框架，它内部WithTimeout创建了 context 跑一批任务，但任务完成时忘了调用 cancel，那么这批任务相关的子 context 就全部滞留。更隐蔽的是，框架把 context 存到了全局变量里，后面的任务不断以它为父 context 派生子 context，导致 context 树无限增长。

第二种误用是 cancel 时机太晚。比如defer cancel()写在某个循环体内部，这个 defer 要等循环结束后才执行。如果一个循环要跑十分钟，这期间创建的 context 全部保持活跃，泄漏风险就潜伏在这里。正确做法是：每个循环迭代内单独创建和 defer cancel，或者显式调用 cancel。

第三种误用是派生的 context 数量过多。一次请求内创建了几千个子 context，每个子 context 只为了拿到一个带超时的ChildContext做一次调用，调用完就丢弃。如果这些子 context 都还挂在父 context 的 children 集合里，父 context 取消时要递归遍历的节点数就会非常大，极端情况下取消操作本身会变成性能瓶颈。

5.4 超时参数的传递路径：一个容易被忽略的坑

不少框架里，WithTimeout不直接放在业务代码里，而是放在基础设施层。比如你写了一个 HTTP 中间件：

func TimeoutMiddleware(timeout time.Duration) func(http.Handler) http.Handler { return func(next http.Handler) http.Handler { return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) { ctx, cancel := context.WithTimeout(r.Context(), timeout) defer cancel() r = r.WithContext(ctx) next.ServeHTTP(w, r) }) } }

如果这个中间件被重复注册，或者链路里有多个中间件都设置了超时，它们的 deadline 会取最早的那个还是最晚的那个？取决于WithDeadline里的判断逻辑：子 context 会优先沿用父级已有的、更早到期的 deadline。所以如果你在链路第一个中间件设置了 2 秒超时，又在后面第二个中间件设置了 5 秒超时，最终生效的是 2 秒。

这个行为合理但容易让人困惑。我见过一个项目，团队在网关层设置了 3 秒超时，又在业务代码里对某个下游单独设置了 5 秒超时，结果那个下游调用始终在 3 秒就断了，排查了半天才意识到是中间件层级的覆盖关系。建议是：超时设置尽量收敛在服务的入口层做一次，业务代码内部只在确有必要时覆盖，而且要意识到覆盖方向是只减不增。

5.5 排查 Context 取消问题的速查表

不过，技术视角归技术视角，这里更需要强调的是，Context 从设计之初的目标就不是单纯的性能优化，而是让并发程序的“取消”成为一等公民，这在设计思想上远比实现本身有价值。

6. 工程落地细节与写作风格说明

写到这里，我已经把 Context 取消信号机制的骨架、血肉、实战和排错经验都过了一遍。最后再分享三个在工作里反复验证过的经验，也是我认为你能把它真正用好的关键。

第一个经验是关于cancel函数的命名规范。在go vet的官方检查器里，如果WithCancel返回的 cancel 函数没有被使用，会直接报编译错误。这提醒我们在代码里给 cancel 函数起名时，不要用_丢弃它。不管什么场景，拿到了 cancel 就要保证它最终被调用，哪怕只是加一条defer cancel()，标志着你拥有取消该 context 的权限且愿意承担这个责任。

第二个经验是关于 context 传递时的第一参数位置。Go 社区的惯例是把 context 作为函数的第一参数，这个惯例不只是代码风格问题，它有一个隐蔽的好处：调用方的go func(ctx context.Context)一眼扫过去就能判断这个函数是否关注取消信号，不需要深入函数体才看到逻辑。遵守惯例意味着维护者能更快理解代码的行为，这在团队合作里是隐形的生产力。

第三个经验是我个人的体会：适度使用 context 做业务传参，但别病态依赖它。我见过有的项目把所有数据库的查询条件、业务枚举、甚至临时状态全塞进 context 里，调用层之间大量隐式耦合，出了问题非常难排查。WithValue应当主要用于跨层传递的 trace 信息、用户身份、租户 ID 这类请求级元数据，业务参数永远走显式的函数参数。

如果要做个类似大脑走一遍的总结，核心的要点其实就是：用Done()做“还有人关心我吗”的哨兵检查，用cancel()明确“我不需要你了”的意图，用WithTimeout锁住“最多等你多久”的边界。把这三个问题想透，Context 对你来说就再也不是一个用了但不知道在干什么的黑盒了。