context.withvalue 返回新 context，原 context 不变；必须显式传递返回值，否则下游获取不到值；http handler 中需用 r = r.withcontext(ctx) 更新请求上下文。
context.WithValue 传参时为什么值突然消失了
因为 context.WithValue 返回的是新 context，原 context 不会被修改。常见错误是调用后没把返回值往上传，下游拿到的还是空 context。
- 必须显式将新 context 作为参数传给下一个函数，不能指望“全局修改”
- 父 goroutine 创建的 context 无法自动透传到子 goroutine，spawn 新 goroutine 时得手动传入
- HTTP handler 中典型写法是：
r = r.WithContext(ctx)，再传给后续逻辑；直接ctx = context.WithValue(r.Context(), key, val)后不替换 request 的 context，handler 内部就拿不到 - key 类型推荐用私有未导出类型（如
type userIDKey struct{}），避免字符串 key 冲突
HTTP 请求里怎么安全塞用户 ID 和 traceID
别用字符串当 key，也别在中间件里反复 WithValue 拼接。标准做法是：一次提取、一次注入、全程复用。
- 入口中间件（如 auth 或 tracing）从 header 或 token 解析出
userID和traceID，用自定义 key 注入到 request context - 后续所有函数只从
req.Context()里取，不再重新解析或覆盖 - 日志打点时优先用
log.WithValues("trace_id", ctx.Value(traceKey))，而不是每次从 header 读——防止中间某层改了 request - 注意：value 类型必须是可比较的（不能是 slice/map/func），否则
ctx.Value()可能 panic
cancel context 被提前关闭导致下游 panic 怎么办
根本原因是上游主动调用 cancel()，但下游还在用这个 context 等待 IO 或 channel。cancel 是不可逆的，一旦触发，ctx.Done() 就永久关闭。
- 不要在非顶层函数里调用
cancel()，它应该只由发起请求的一方控制 - 下游等待时务必检查
ctx.Err() != nil再处理 error，而不是只监听 - 数据库查询、HTTP client 调用等都支持传 context，它们内部会自动响应 cancel；但自己写的 for-select 循环必须显式判断
ctx.Err() - 测试时容易漏掉：用
context.WithTimeout后忘记 defer cancel，会导致 goroutine 泄漏
为什么用 context.Value 存用户信息总被说“设计坏”
不是 context.Value 本身有问题，而是它被用在了不该承担职责的地方——它只适合传递“请求生命周期内不变的元数据”，不是通用状态容器。
- 如果函数需要频繁读写某个字段（比如“当前语言”“灰度分组”），更适合做成显式参数或结构体成员，而非藏在 context 里
- context 里塞太多东西会模糊接口契约：调用方不知道要塞什么，实现方也不知道哪些 key 必须存在
- 调试困难：IDE 不提示，运行时才报
nil，且 stack trace 不体现丢失路径 - 真正该放的只有：request-scoped identity（
userID）、tracing（spanID）、deadline 控制（timeout）这类跨多层、不参与业务逻辑但影响行为的值
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
