context 专用于传递取消信号和超时控制，不可滥用传业务数据；须用私有类型作 key，值只读；cancel 必须显式且仅调用一次；监听取消应使用 select + ctx.done()。
context 用来传递取消信号和超时控制，不是用来传业务数据的
很多人误以为 context.Context 是个通用的“请求上下文”，把用户 ID、配置、数据库连接都塞进去。这是反模式。它的设计目标非常明确：跨 goroutine 传递取消（cancel）、截止时间（Deadline）、超时（Timeout）和少量不可变的元信息（如 trace ID）。业务数据该用参数传就传参数，该用结构体字段就放结构体里。
滥用 context.WithValue 会导致调用链污染、类型不安全、难以测试，且一旦 key 冲突或类型断言失败，panic 往往发生在很深的调用栈里，排查困难。
- 只用预定义的
context.TODO()或context.Background()作为根 context - 业务键必须是私有类型（避免第三方包 key 冲突），例如
type userKey struct{}，而非string - 所有
WithValue的值应是只读的；写操作必须通过其他机制（如 channel 或 mutex 包裹的结构体）完成
cancel 函数必须被显式调用，且只能调用一次
context.WithCancel 返回的 cancel 函数不是“自动触发”的钩子，它不会在 parent context 取消时被调用——它只是让子 context 进入“已取消”状态。你得自己决定何时调用它，比如在 HTTP handler 返回前、在 goroutine 退出前、或收到某个事件后。
重复调用 cancel 不会 panic，但也没任何效果；而漏调则导致 goroutine 泄漏、资源未释放、定时器持续运行等典型并发问题。
立即学习“go语言免费学习笔记（深入）”；
- HTTP handler 中，应在 defer 中调用
cancel，但注意别在中间件里提前调用，否则后续 handler 拿到的是已取消的 context - 启动新 goroutine 时，若传入带 cancel 的子 context，务必确保该 goroutine 有明确退出路径，并在退出前调用
cancel（或由上层统一管理） - 不要把
cancel函数作为返回值暴露给调用方，除非你明确要交出取消权（如StartServer(ctx)返回Stop()）
select + context.Done() 是监听取消的唯一推荐方式
不能靠轮询 ctx.Err() != nil 来判断是否该退出，因为这既低效又可能错过取消时机。正确做法是把 <ctx>.Done()</ctx> channel 和其它 channel 一起放进 select 语句中，让 goroutine 在任意一个 channel 就绪时响应。
ctx.Done() 关闭后，其内部 channel 会立即可读，读取返回 nil；如果 context 尚未取消，则该 case 会阻塞，直到取消发生。
select {
case <-ctx.Done():
return ctx.Err() // 退出并返回错误
case result := <-ch:
return result
case <-time.After(100 * ms):
return errors.New("timeout")
}
- 永远不要在
select外单独检查ctx.Err()作为循环条件（如for ctx.Err() == nil），这会吃 CPU 且不响应取消 - 如果函数内有多个阻塞点（如多次 HTTP 请求、多次 channel receive），每个阻塞点前都应有对应的
select监听ctx.Done() -
context.Deadline()和context.Timeout()本质也是通过Done()实现的，无需额外处理
HTTP Server 和 database/sql 自动支持 context，但需手动透传
Go 标准库的 http.Server 启动时会为每个请求创建带取消能力的 context（当客户端断开时自动 cancel），database/sql 的 QueryContext、ExecContext 等方法也接受 context 并在取消时中断查询。但这些能力不会自动“穿透”到你的业务逻辑里——你得一路把 context 从 handler 传进 service，再传进 repository，不能中途丢掉或换掉。
常见错误是 handler 里用了 context.WithTimeout，但在调用下游函数时又传了 context.Background()，导致超时失效。
- handler 中获取的
r.Context()应作为起点，所有下游调用都基于它派生新 context（如加 timeout、加 value） - 不要在 middleware 里无条件替换
r = r.WithContext(newCtx)，除非你完全掌控生命周期；更安全的做法是在 middleware 中增强 context（context.WithValue）而非替换 - 第三方库若不支持 context（如老版本 redis-go），需自行包装或升级；强行用
context.Background()接入会破坏整条链路的取消传播
context 的真正难点不在 API 使用，而在于取消边界的识别：哪些 goroutine 必须响应取消？哪些资源必须清理？哪些 channel 必须关闭？这些决策无法靠工具自动推导，得结合业务流程图一条路径一条路径地梳理。漏掉一个，就可能卡住整个服务。
