context.Context 到底怎么用

先抛结论：`context.Context` 的核心使命是传递取消信号、超时控制和有限数量的请求级元数据，而不是当作一个“万能键值袋”来存业务数据。滥用 `WithValue` 是最常见也最危险的走偏方向。

为什么不能把 context 当 map 用

很多人一看到 `WithValue` 就下意识想把用户 ID、token、traceID 往里塞——但 `Context` 从来就不是为通用键值存储而生的。它的 `Value` 查找是链式遍历，层级越深性能越差；更致命的是，它既没有类型安全，也没有生命周期管理，更无法被静态检查。你传进去一个 `string`，取出来时可能拿到了一个 `int`，运行时报错:`panic: interface conversion: interface {} is string, not int`——这种错，在生产环境里一旦发生就是事故。 真实项目里最容易踩的坑包括： - 在中间件里写 `ctx = context.WithValue(ctx, "user_id", userID)`，下游却用 `ctx.Value("user_id").(int)` 强转。只要上游没设置或者类型变了，直接 panic。 - 把数据库连接、HTTP client 这类长生命周期对象塞进 context，导致 goroutine 泄漏或者连接复用混乱。 - 用字符串字面量当 key（比如 `"user_id"`），多个包重复定义，互相覆盖还很难排查。

正确传递取消和超时信号

这才是 `context.Context` 真正的设计价值：让一次请求内所有 goroutine 能够被统一中断。举个典型场景：HTTP handler 启动了三个子 goroutine 分别去查缓存、查数据库、调第三方 API，只要客户端断开连接，整条链路就应该立刻退出，不浪费任何资源。 实操上几个要点： - 永远从入参接收 `ctx context.Context`，不要自己造 `context.Background()` 或 `context.TODO()`（测试或顶层初始化除外）。 - 超时优先用 `WithTimeout` 或 `WithDeadline`，别自己折腾 timer + channel 那套。 - 调用下游函数时，记得把当前 `ctx` 传下去——尤其是那些明确支持 context 的接口，比如 `http.Client.Do`、`database/sql.QueryContext`、`time.AfterFunc` 等。 - 自己写的阻塞操作（如轮询、sleep），必须显式监听 `<-ctx.Done()` 并返回 `ctx.Err()`。 示例： ```php func fetchUser(ctx context.Context, id int) (User, error) { // 数据库查询自动响应 ctx 取消 row := db.QueryRowContext(ctx, "SELECT name FROM users WHERE id = ?", id) var name string if err := row.Scan(&name); err != nil { return User{}, err } return User{Name: name}, nil } ```

安全地传少量元数据

如果真的非要传数据（比如 traceID、requestID），必须满足两个条件：第一，数据是只读、不可变的；第二，用私有类型做 key，避免冲突。 正确的写法是： - 定义 key 类型：`type requestIDKey struct{}`，而不是 `const RequestIDKey = "req_id"` - 传值：`ctx = context.WithValue(ctx, requestIDKey{}, "abc123")` - 取值：`if rid, ok := ctx.Value(requestIDKey{}).(string); ok { ... }` 注意这里的 `requestIDKey{}` 是一个空结构体，零内存占用，每次构造都是一个新类型实例——这样就能防止不同包误用同一个字符串 key 导致相互覆盖。

别忽略 cancel 函数的调用时机

`WithCancel`、`WithTimeout`、`WithDeadline` 都会返回一个 `cancel func()`，这个函数**必须被调用**，否则底层的 `done` channel 不会关闭，goroutine 和 timer 都不会释放。 典型错误： - 在 defer 中调用了 `cancel()`，但函数提前 return 了，defer 没执行（实际上 defer 总会执行，但可能被误放在 return 之后？不对，defer 在函数返回时执行，如果 panic 也会执行。但常见错误是在某些分支中忘了 defer） - 把 `cancel` 传给子 goroutine，父 goroutine 已经退出，子 goroutine 拿到的是已失效的函数。 - 忘记调用，尤其是在 error early return 的分支里漏掉。 最佳实践：**在函数入口立刻 defer**，哪怕后面有多个 return 也能确保释放： ```php func handleRequest(ctx context.Context) { ctx, cancel := context.WithTimeout(ctx, 5*time.Second) defer cancel() // 这里保证一定执行 if err := doSomething(ctx); err != nil { return // cancel 仍会执行 } } ``` 真正难的不是怎么写，而是判断该不该用 context —— 一次 HTTP 请求、一个 RPC 调用、一个后台任务，这些边界很清晰；而跨 service、跨进程、或者需要持久化存储的数据，context 就不该出现。