go 的 context 不是自动传递机制，必须显式传参、每次派生返回新实例；漏传 ctx、未更新请求对象、key 类型不当或误用 value 存状态，均导致值丢失或取消失效。
直接说结论：Go 的 context 不是“自动传递”的机制，它必须显式作为函数第一个参数传入，且每次派生（如 WithValue、WithTimeout）都返回新 context，原 context 不变——漏传、不更新、乱用 key，值就丢了，取消就收不到。
context.WithValue 传的值为什么总拿不到
- 常见错误是调用
context.WithValue(ctx, key, val)后没把返回的新ctx往下传，下游拿到的还是旧的、没值的 context - HTTP handler 中尤其典型：只写
ctx = context.WithValue(r.Context(), key, val)，但没执行r = r.WithContext(ctx)，后续中间件或 handler 函数调用r.Context()仍取不到 - key 必须是可比较类型；推荐用私有未导出结构体（如
type userIDKey struct{}），避免字符串 key 冲突或拼写错误 -
context.Value只适合存请求生命周期内只读、不变的元数据（如 traceID、userID），不是状态容器；频繁读写字段应改用显式参数
context.WithCancel 和 WithTimeout 的 cancel 函数谁来调
-
cancel函数只能由创建它的那一层调用，通常是发起请求的顶层 goroutine（如 HTTP handler 入口、主任务调度器） - 子 goroutine 或被调用函数绝不应该调用 cancel，否则会提前终止整个链路，导致下游 panic 或资源未释放
- 使用
WithTimeout后必须defer cancel()，否则 timer 不释放，goroutine 泄漏（尤其在循环中反复创建时） -
cancel()是不可逆操作：一旦调用，ctx.Done()永久关闭，ctx.Err()永远返回context.Canceled
ctx.Done() 在 for-select 循环里怎么写才安全
- 不能只监听
就退出，必须在退出前检查 <code>ctx.Err() != nil，否则可能把正常错误误判为取消 - 长时间阻塞操作（如数据库查询、HTTP 调用）应优先使用支持 context 的 SDK（如
db.QueryContext、http.NewRequestWithContext），它们内部已处理信号响应 - 自己写的 for-select 循环需显式判断：
for {
select {
case <hr><p>真正容易被忽略的点是：context 的树形生命周期完全依赖<strong>调用链上的每一次手动传递</strong>。它没有魔法，不靠反射，不靠全局变量，也不靠框架自动注入——你少传一次、错传一层、或 key 类型不一致，整条链就断了。写完记得反向检查：从入口到最深的子函数，每个 <code>ctx</code> 参数是不是都来自上一层返回值？每个 <code>cancel</code> 是不是只在该层 defer 或条件触发？每个 <code>Value</code> 的 key 是不是严格复用同一个类型？</p>golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
