go 的 context.context 必须显式传递，因 http handler、goroutine 启动、db 查询等关键路径均依赖传入的 ctx 实现取消与超时控制；若用 context.background() 或存入 struct，则下游无法感知上层取消，导致 goroutine 泄漏和资源浪费。
为什么 context.Context 不能靠全局变量或函数参数“手动传”？
因为 Go 的 HTTP handler、goroutine 启动、数据库调用这些关键路径都要求你显式接收并向下传递 ctx，否则一旦上层取消，下游完全感知不到。常见错误是只在入口处接收 ctx，但调用 http.Client.Do 或 db.QueryContext 时传了 context.Background() —— 这等于主动放弃取消能力。
实操建议：
- 所有接受
context.Context的函数（如http.NewRequestWithContext、time.AfterFunc、sql.DB.QueryContext）必须传入上游传来的ctx，而非新建 - 不要把
ctx存进 struct 字段长期持有——它生命周期由调用方控制，可能中途被 cancel - 若需携带请求级数据（如用户 ID），用
context.WithValue，但值类型必须是自定义未导出类型，避免 key 冲突
如何正确触发一次 HTTP 请求的取消？
典型场景：前端发起请求后快速关闭标签页，后端还在等下游 API 响应。这时仅靠 http.Server 的 ReadTimeout 不够，必须让 http.Client 主动中断连接。
实操建议：
- 用
context.WithTimeout或context.WithDeadline包装原始ctx，再传给http.NewRequestWithContext -
http.Client本身不管理超时，超时逻辑全靠ctx驱动；若没传ctx，即使设了client.Timeout也只作用于单次连接建立，不覆盖整个请求生命周期 - 注意：
ctx.Err()在取消后返回context.Canceled或context.DeadlineExceeded，不是所有错误都该重试
示例片段：
ctx, cancel := context.WithTimeout(r.Context(), 5*time.Second)
defer cancel()
req, _ := http.NewRequestWithContext(ctx, "GET", "https://api.example.com/data", nil)
resp, err := client.Do(req)
if err != nil {
if errors.Is(err, context.DeadlineExceeded) {
// 明确是超时，不是网络错误
}
}
context.WithCancel 和 context.WithTimeout 选哪个？
二者本质都是生成可取消的 ctx，区别在于谁来触发取消：WithCancel 需手动调用 cancel() 函数；WithTimeout 在时间到时自动调用 cancel()。别误以为 WithTimeout 更“高级”——它底层就是封装了一次 WithCancel + time.AfterFunc。
实操建议：
- 需要响应外部信号（如另一个 goroutine 发送停止指令）时，用
context.WithCancel - 明确知道最长容忍耗时（如 RPC 调用上限 2s），用
context.WithTimeout更简洁 - 永远记得
defer cancel()，否则可能泄漏 goroutine（尤其是WithCancel） - 避免嵌套多次
WithCancel：一个ctx只需一次取消源头，多层 cancel 函数容易误调或漏调
为什么数据库查询用了 QueryContext 还是不响应取消？
常见现象：HTTP 请求已超时，但 pgx 或 mysql 驱动仍在后台跑 long-running query，日志里看不到 context canceled 错误。根本原因不是代码写错，而是驱动或数据库本身对 cancel 的支持程度不同。
实操建议：
- PostgreSQL（
pgx）默认支持 cancel：只要ctx被 cancel，驱动会发 CancelRequest 协议包给服务端 - MySQL（
go-sql-driver/mysql）需开启interpolateParams=true且版本 ≥ 1.6 才能可靠响应ctx取消 - SQLite 不支持服务端 cancel，
QueryContext仅能中断 Go 层等待，无法中止正在执行的 SQL - 验证是否生效：在查询前加
select { case ，再用 <code>ctx控制，看是否提前退出
真正难处理的是那些不支持 cancel 的中间件或 SDK——它们可能把 ctx 当摆设。这种时候得靠超时兜底，或改用支持 cancel 的替代方案。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
