Context 详解：如何在微服务链路中传递取消信号与超时控制

"In Go servers, each incoming request is handled in its own goroutine. Request-scoped values like user identity and timeouts should be passed along." ------ Go Blog

在 Go 语言中，go func() 就像泼出去的水，一旦启动，父协程就很难直接控制它了。

试想一个场景：

你的 Web 服务器接收到一个 HTTP 请求，你启动了 3 个 Goroutine 分别去查询数据库、Redis 和 RPC 服务。

突然，用户觉得太慢，关闭了浏览器（断开了连接）。

问题来了：那 3 个后台 Goroutine 还在拼命干活，占用 CPU 和 IO，但它们的结果已经没人要了。这就是Goroutine 泄露和资源浪费。

Java 可能通过 ThreadLocal 或 interrupt 机制解决，而 Go 给出的答案是标准库：context。

它不仅是 Go 并发的"遥控器"，更是微服务链路追踪（Tracing）的基石。今天，我们就深入 context 源码，拆解它是如何构建**取消树（Cancellation Tree）**的。

1. 接口虽小，功能巨大

context 的核心是一个接口，定义在 src/context/context.go 中。它的定义非常精炼：

复制代码

type Context interface {
    // 返回一个 Deadline，告诉接收者什么时候该"死"
    Deadline() (deadline time.Time, ok bool)

    // 返回一个 Channel。当 Context 被取消或超时时，这个 Channel 会被 close。
    // 这是核心方法，用于接收取消信号。
    Done() <-chan struct{}

    // 返回 Context 被取消的原因（Canceled 还是 DeadlineExceeded）
    Err() error

    // 获取 Key 对应的 Value（用于传递 Request-Scoped 数据）
    Value(key any) any
}

Go 的设计哲学是侵入式 的：任何可能阻塞或耗时的函数，都应该把 ctx Context 作为第一个参数。

2. 取消树 (Cancellation Tree)

context 的各种实现（WithCancel, WithTimeout）在底层构建了一棵多叉树。

根节点 ：通常是 context.Background() 或 context.TODO()。它们是空的，永远不会被取消。
子节点 ：通过 WithCancel 等方法派生。
传播规则 ：父节点取消，所有子孙节点会自动取消；子节点取消，不会影响父节点。

2.1 可视化流程

复制代码

graph TD
    Root[Background] --> A[WithCancel (Ctx A)]
    A --> B[WithTimeout (Ctx B)]
    A --> C[WithValue (Ctx C)]
    B --> D[DB Query]
    B --> E[RPC Call]
    
    style Root fill:#f9f,stroke:#333
    style A fill:#bbf,stroke:#333
    style B fill:#bfb,stroke:#333
    
    classDef action fill:#ddd,stroke:#333,stroke-dasharray: 5 5;
    class D,E action;

场景解析：

如果 Ctx A 被取消了（调用了 cancel() 函数）：

Ctx A 的 Done channel 关闭。
它会递归地找到所有子节点（Ctx B, Ctx C），并调用它们的 cancel 方法。
Ctx B 关闭，进而通知下游的 DB Query 和 RPC Call 停止工作。

3. 源码深度剖析：取消是如何传播的？

WithCancel 是最基础的实现。让我们看看源码是如何把父子节点"挂钩"的。

复制代码

// src/context/context.go

func WithCancel(parent Context) (ctx Context, cancel CancelFunc) {
    // 1. 创建一个新的 cancelCtx 结构体
    c := newCancelCtx(parent)
    
    // 2. 【关键】构建父子关系：propagateCancel
    // 将自己挂到父节点的 children map 中
    propagateCancel(parent, &c)
    
    return &c, func() { c.cancel(true, Canceled, nil) }
}

3.1 挂载逻辑 (propagateCancel)

Go 必须处理一种复杂情况：parent 可能是一个自定义的 Context，并不支持标准的取消机制。

复制代码

func propagateCancel(parent Context, child canceler) {
    done := parent.Done()
    
    // 如果父节点永远不会取消（比如 Background），那就啥也不用干
    if done == nil {
        return 
    }

    // 检查父节点是否已经取消了
    select {
    case <-done:
        // 父节点已挂，子节点直接死
        child.cancel(false, parent.Err(), nil)
        return
    default:
    }

    // 找到父节点中最近的那个标准 cancelCtx
    if p, ok := parentCancelCtx(parent); ok {
        p.mu.Lock()
        if p.err != nil {
            // 父节点已经被取消了
            child.cancel(false, p.err, nil)
        } else {
            // 【核心】将子节点加入父节点的 children map
            if p.children == nil {
                p.children = make(map[canceler]struct{})
            }
            p.children[child] = struct{}{}
        }
        p.mu.Unlock()
    } else {
        // 如果找不到标准的父节点，就开启一个 goroutine 傻傻地监听
        go func() {
            select {
            case <-parent.Done():
                child.cancel(false, parent.Err(), nil)
            case <-child.Done():
            }
        }()
    }
}

Go 尽量尝试建立内部的 map 引用关系（高效）。但如果父节点是第三方库实现的 Context，它只能启动一个新的 Goroutine 去监听 parent.Done()，这虽然会有额外的 Goroutine 开销，但保证了兼容性。

3.2 取消逻辑 (cancel)

当调用 cancel() 时：

关闭 Done channel：通知监听者。
递归取消子节点 ：遍历 children map，逐个调用子节点的 cancel。
断绝父子关系 ：将自己从父节点的 children map 中移除（防止内存泄露）。

4. 隐蔽的性能陷阱：WithValue

除了控制流，Context 还常用于传递数据（如 TraceID、UserInfo）。

WithValue 返回的是 valueCtx。

复制代码

type valueCtx struct {
    Context      // 嵌入父 Context
    key, val any // 当前节点的 KV
}

4.1 查找过程：O(N) 的链表扫描

当你调用 ctx.Value(key) 时：

复制代码

func (c *valueCtx) Value(key any) any {
    if c.key == key {
        return c.val
    }
    // 递归向上查找父节点
    return c.Context.Value(key)
}

这是一个典型的单向链表查找。

如果你在一层层中间件中疯狂地 WithValue，这棵树会变得非常深。每次查找都要回溯到根节点，时间复杂度是 O(N)（N 是层数）。

不要用 Context 当万能字典。
只放必须的、请求作用域的数据（如 TraceID）。
不要放可选参数或业务大对象。

5. 超时控制的最佳范式

如何写一个能够响应 Context 取消的数据库查询？

复制代码

func QueryDB(ctx context.Context, query string) error {
    // 1. 创建一个带 buffer 的 channel 用于接收结果
    // 避免 goroutine 泄露（如果 ctx 取消了，worker 还能写入退出）
    done := make(chan error, 1)

    go func() {
        // 模拟耗时操作
        time.Sleep(2 * time.Second)
        // 真正的业务逻辑...
        done <- nil
    }()

    // 2. 多路复用：同时监听 业务完成 和 Context 取消
    select {
    case err := <-done:
        return err // 业务正常结束
    case <-ctx.Done():
        // Context 取消或超时
        return ctx.Err() // 返回 context.Canceled 或 DeadlineExceeded
    }
}

func main() {
    // 设置 1 秒超时
    ctx, cancel := context.WithTimeout(context.Background(), 1*time.Second)
    defer cancel() // 【关键】无论如何都要调用 cancel，释放 timer 资源

    err := QueryDB(ctx, "SELECT * FROM users")
    if err != nil {
        fmt.Println("Query failed:", err)
    }
}

注意点：

在使用 WithTimeout 或 WithDeadline 时，必须 defer cancel()。

因为这两种 Context 内部会启动一个 time.Timer。如果不主动 cancel，那个 Timer 就会一直存活直到超时时间到达，导致资源泄露。

6. 总结

Context 是 Go 并发编程的神经系统。

控制流 ：通过 Done() channel 广播取消信号，底层利用 children map 实现级联取消。
数据流 ：通过 Value() 传递请求元数据，底层是链表查找，注意性能。
生命周期 ：WithTimeout 必须配合 defer cancel() 使用。