Go context 底层实现全解析：cancelCtx 取消树、timerCtx 定时器与 valueCtx 链式查找

引言：用法会背，源码才是分水岭

「context 怎么用」——WithCancel、WithTimeout、WithValue 三个函数张口就来，面试到这里只算及格。真正的区分题是：

• WithCancel 创建的父子 context，底层是如何建立关联的？
• Done() 返回的通道为什么建议只在 select 里读，而 cancel() 会做什么？
• WithTimeout(parent, 10*time.Second) 里，如果父 context 只剩 3 秒就到期，定时器还建吗？
• WithValue 存的值，为什么键必须是可比较类型？

站内 第 05 期 context 包详解 讲了用法，第 21 期 讲了超时控制实践，本篇直达源码层——context 包的本质是四种接口实现类型的组合。本文所有源码细节均对照 go1.26.0 的 src/context/context.go 逐一核实。

一、四种实现类型：一切皆是组合

context 包没有复杂的继承体系，Context 接口只有 Deadline、Done、Err、Value 四个方法，全部能力由四种具体类型组合出来：

Background() 和 TODO() 返回的都是 emptyCtx，Done() 返回 nil、Err() 返回 nil、Value() 返回 nil——它们是整棵 context 树的根，本身不可取消、无超时、无值。这是面试第一问「context 能不能取消」的答案来源。

二、cancelCtx：取消信号与传播树的核心

cancelCtx 是整棵取消树的骨架，它的结构体（照录 go1.26.0 源码）：

type cancelCtx struct {
	Context

	mu       sync.Mutex            // protects following fields
	done     atomic.Value          // of chan struct{}, created lazily, closed by first cancel call
	children map[canceler]struct{} // set to nil by the first cancel call
	err      atomic.Value          // set to non-nil by the first cancel call
	cause    error                 // set to non-nil by the first cancel call
}

四个关键点：

1. done 通道惰性创建。 第一次调用 Done() 时才在锁内 make(chan struct{})，不取消的场景下完全不分配通道，这是性能优化的第一步。源码注释「created lazily, closed by first cancel call」说明了这个设计。

2. 父子通过 children map 关联。 每个 cancelCtx 持有一个 map[canceler]struct{}，子节点创建时注册进来。canceler 接口只有 cancel(removeFromParent bool, err, cause error) 和 Done() 两个方法，*cancelCtx 和 *timerCtx 都实现了它。

3. cancel 时自底向上广播。 取消一个节点时：先把 children 置为 nil（注释「set to nil by the first cancel call」），然后遍历所有子节点递归调用它们的 cancel(false, ...)——取消沿树向下传播，整棵子树一次性失效。

4. err 与 cause 分离。 err 只有两种取值：context.Canceled 或 context.DeadlineExceeded；cause 则记录具体原因（WithCancelCause 传入）。这回答了「取消后如何拿到具体错误原因」——用 context.Cause(ctx)：

package main

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

func main() {
	ctx, cancel := context.WithCancelCause(context.Background())
	go func() {
		time.Sleep(100 * time.Millisecond)
		cancel(errors.New("下游 MySQL 连接超时"))
	}()

	select {
	case <-ctx.Done():
		// 区分「被取消」和「为什么被取消」
		fmt.Println("err :", ctx.Err())             // context canceled
		fmt.Println("cause:", context.Cause(ctx))   // 下游 MySQL 连接超时
	}
}

WithCancelCause 和 Cause 是 Go 1.20 引入的。之前只能用 fmt.Errorf("...: %w", ctx.Err()) 包裹，错误链又长又乱；现在 cause 直接挂在 context 上，链路清晰。这部分与 第 27 期内存模型 提到的「跨 goroutine 传递状态」思路一脉相承。

三、propagateCancel：父取消时，子节点怎么收到通知？

这是源码里最容易被追问的一段。子节点创建时调用 propagateCancel(parent, child)，它分两条路径：

路径 A：直接挂到父级 cancelCtx 的 children。 如果父级是（或内嵌了）*cancelCtx，子节点直接注册进父节点的 children map。父节点取消时沿 map 递归取消，开销 O(1) 定位、O(n) 广播。

路径 B：注册 AfterFunc 兜底。 如果父级是自定义实现（比如 http.Request 里的 context），无法直接挂 children，就用 AfterFunc(parent, func() { child.cancel(false, parent.Err(), parent cause) }) 注册一个回调——父级 done 通道关闭时触发子节点取消。这是 Go 1.21 为 context 包新增的 AfterFunc 函数，你可以在自己的 context 实现里提供同名方法来优化这条路径。

取消函数的第二个作用：removeChild。 正常代码都会 defer cancel()。cancel 除了关闭自己的 done、广播子树，还会把自己从父节点的 children 中删除（源码里 removeFromParent 参数控制）。否则父 context 长期存活时，被取消的子节点会永远留在父节点的 map 里，造成内存泄漏——这是 context 面试中最常考的陷阱，也是 第 17 期 goroutine 泄漏检测 的姊妹问题。

四、timerCtx：超时控制的定时器何时启动？

WithTimeout(parent, timeout) 等价于 WithDeadline(parent, time.Now().Add(timeout))，而 WithDeadline 的源码揭示了一个反直觉的优化：

if cur, ok := parent.Deadline(); ok && cur.Before(d) {
	// The current deadline is already sooner than the new one.
	return WithCancel(parent)
}

如果父级 deadline 更早，直接返回 WithCancel(parent)，根本不创建定时器！ 因为父级到期时取消会自然传播下来，子节点没必要自己再开一个 timer。只有当子节点 deadline 严格早于父级时，才创建自己的 time.AfterFunc：

dur := time.Until(d)
if dur <= 0 {
	c.cancel(true, DeadlineExceeded, cause) // deadline has already passed
	return c, func() { c.cancel(false, Canceled, nil) }
}
c.mu.Lock()
defer c.mu.Unlock()
if c.err.Load() == nil {
	c.timer = time.AfterFunc(dur, func() {
		c.cancel(true, DeadlineExceeded, cause)
	})
}

三个细节值得背下来：

1. 定时器也是惰性的。 代码走到 c.timer = time.AfterFunc(...) 才启动，且加锁检查 c.err.Load() == nil——如果创建期间已经被取消了（比如父级恰好在注册子节点时取消），就不浪费一个 timer。
2. deadline 已过期立即取消，不等 timer。
3. 手动 cancel 时先停 timer。 timerCtx.cancel 先委托给内嵌的 cancelCtx.cancel，然后 c.timer.Stop() 并置 nil——及时释放计时器资源。这呼应了 第 34 期定时器底层 提到的「定时器资源要及时回收」。

timerCtx 的结构体照录如下，注意它是内嵌 cancelCtx 而不是自己实现取消逻辑：

type timerCtx struct {
	cancelCtx
	timer *time.Timer // Under cancelCtx.mu.
	deadline time.Time
}

五、valueCtx：链式查找的"俄罗斯套娃"

valueCtx 可能是四种类型里最简单的：

type valueCtx struct {
	Context
	key, val any
}

它就是一个单向链表节点：每个节点存一对键值，指向父节点。Value(key) 查找时沿父链一路向上比对 key——父链越长，查找越慢。WithValue 有三条硬约束，全部来自源码 panic：

if parent == nil {
	panic("cannot create context from nil parent")
}
if key == nil {
	panic("nil key")
}
if !reflectlite.TypeOf(key).Comparable() {
	panic("key is not comparable")
}

由此推出三条面试标准答案：

1. key 不能是 nil，且必须是可比较类型（接口的动态类型要支持 ==），否则直接 panic。
2. 不要直接传 string/int 这类基础类型当 key，应该用自定义的空结构体类型（type ctxKey struct{}），避免不同包的 key 撞名——这是 Go 官方 FAQ 的建议。
3. 不要把大对象塞进 valueCtx。每次 WithValue 都新建一个链表节点，传递大 map 语义上可行，但每个请求都拷贝引用链，GC 压力大；高频路径传小值或指针。

六、面试追问速查清单

相关阅读

• Go context 包详解：并发编程中的取消控制与超时管理
• 为什么你的 Go 服务需要 Context？超时控制与取消传播
• Go Channel 底层实现全解析：hchan 环形队列、sudog 与阻塞唤醒
• goroutine 泄漏检测实战：如何发现与修复泄漏问题？

本系列持续更新中，本文是「Go语言面试题」系列第 36 篇。

版本说明

本文基于 Go 标准库 src/context/context.go 源码编写，所有结构体字段、函数逻辑逐字对照 go1.26.0（2026-11-07 核对，官方源码：go.dev/src/context/context.go，本地 $GOROOT/src/context/context.go 可对照）。本文无第三方依赖；文中提到的 WithCancelCause / Cause（Go 1.20）、AfterFunc（Go 1.21）均为当前长期支持版本已包含的标准能力，使用 Go 1.21 及以上版本编译运行本文代码即可。

📮 关注公众号「GO语言入门之路」

每周更新 Go + AI 应用开发实战：AI 面试官完整项目、MCP、Agent 工程化，完整源码随文章首发。

微信扫码，或搜索「GO语言入门之路」关注，第一时间获取系列更新与源码，不再错过任何一篇。