Golang并发编程中context的作用_Golang协程控制与取消机制

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() // &#36864;&#20986;&#24182;&#36820;&#22238;&#38169;&#35823; 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 必须关闭？这些决策无法靠工具自动推导，得结合业务流程图一条路径一条路径地梳理。漏掉一个，就可能卡住整个服务。