go context是标准库原生机制，必须显式传递、正确派生和及时取消；漏传导致协程泄漏，误用withvalue引发键冲突，不调cancel造成资源浪费。
Go 的 context 不是“框架组件”，而是标准库原生机制；它不依赖任何框架，但所有主流框架（如 Gin、Echo、gRPC）都强制遵循其传递和取消逻辑。用错 Context，不是功能不生效，而是协程泄漏、超时失效、资源卡死——这些问题在线上环境往往延迟暴露。
为什么不能在函数参数里漏传 ctx
Go 的 Context 必须显式传递，无法隐式继承或从全局获取。一旦某个中间函数没把 ctx 传下去，下游的 http.Client.Do、database/sql.QueryContext 或自定义 goroutine 就彻底脱离生命周期控制。
- 常见错误现象：HTTP handler 已超时返回 504，但后台 goroutine 仍在跑数据库查询，连接池耗尽
- 典型场景：日志中间件、鉴权逻辑、DB 查询封装层 —— 这些地方最容易把
ctx当作“可选参数”忽略 - 正确做法：所有可能阻塞或启动子 goroutine 的函数，第一个参数必须是
ctx context.Context；IDE 可配检查规则拦截无ctx参数的 I/O 函数调用
WithValue 的键必须是自定义类型，不能用 string
用字符串当键看似方便，实则埋下运行时冲突隐患：不同包里都用 "user_id" 当 key，Value 查找会取到错误的值，且编译器完全无法发现。
- 正确写法：
type userIDKey struct{}然后ctx = context.WithValue(ctx, userIDKey{}, 123) - 性能影响：每次
Value查找需向上递归遍历父节点，深层嵌套 + 频繁调用会拖慢关键路径 - 更安全的替代：优先用函数参数传值；仅对跨多层中间件、且无法改签名的链路追踪 ID、请求 ID 等元数据才用
WithValue
WithCancel / WithTimeout 返回的 cancel 函数必须调用
不调用 cancel() 不仅浪费内存（timerCtx 持有定时器，cancelCtx 持有 map 和 channel），还会让父 Context 无法及时感知子任务结束，破坏级联取消语义。
- 常见坑：defer cancel() 写在错误分支外，但函数提前 return；或 panic 后 defer 未执行
- 建议模式：
ctx, cancel := context.WithTimeout(parent, time.Second*5) defer cancel() // 放在函数最开头，不管后续怎么 return
- 注意：
WithTimeout创建的 timerCtx 在超时后会自动调用cancel，但手动取消仍需你来触发；未超时就主动取消时，cancel()是唯一释放资源的途径
Context 的真正复杂点不在 API，而在“谁该创建、谁该取消、谁该监听”。一个 HTTP 请求里，Background 只能出现在 main 入口或测试 setup；TODO 仅用于尚未确定上下文来源的 stub 函数；所有业务逻辑必须基于传入的 ctx 派生，而不是自己 new 一个。漏掉这一层约束，再多的超时设置也形同虚设。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
