context.withvalue仅用于传递请求级不可变元数据，90%问题源于key类型冲突、未传递新ctx或误作函数参数；必须用未导出struct作key、双返回值取值、避免传指针/map/大结构体。
Context 不是用来传业务参数的，强行用 context.WithValue 塞订单 ID、用户邮箱或配置项，等于在调用链里埋雷——可读性崩坏、类型失控、测试困难、后期维护成本翻倍。
为什么 context.WithValue 总是取不到值
根本不是 API 调用错了，而是误以为它会“修改”原 context。它实际返回一个全新 context，而你没把新值传下去。
- 错误写法：
ctx = context.WithValue(ctx, key, val)后，直接调用下游函数却仍传入旧ctx，下游ctx.Value(key)必然返回nil - HTTP 中间件里常见漏操作：改完
r.Context()没调r = r.WithContext(newCtx)，后续 handler 拿到的还是原始 request - key 用
string定义（如"user_id"）：跨包时内存地址不同，==判断失败，值永远取不到
自定义 key 的正确写法必须用未导出空 struct
不是“推荐”，是唯一能避免静默失败的方式。IDE 可跳转、编译器能校验、不同包不会冲突。
- 定义方式：
type userIDKey struct{}（小写开头，不导出） - 全局唯一实例（可选但建议）：
var userIDKeyKey = userIDKey{} - 存取严格配对：
ctx = context.WithValue(ctx, userIDKeyKey, user)→user := ctx.Value(userIDKeyKey).(User) - 取值务必用双返回值断言：
if u, ok := ctx.Value(userIDKeyKey).(User); ok { ... }，否则 panic
HTTP handler 到 DB 查询之间怎么传 context
关键不是“怎么传”，而是“谁来派生”。handler 接收的 ctx 来自 r.Context()，它已绑定请求生命周期；DB 层必须用这个 ctx 或其派生体，不能自己 new。
- 绝对禁止：
db.QueryContext(context.Background(), ...)—— 超时和取消信号彻底断掉 - 正确做法：
db.QueryContext(ctx, ...)直接复用入参ctx - 若需额外超时（如 DB 最多等 2 秒）：
dbCtx, cancel := context.WithTimeout(ctx, 2*time.Second)，再传给QueryContext，且记得defer cancel() - goroutine 中启动 DB 查询？必须显式传入
ctx：go func(ctx context.Context) { db.QueryContext(ctx, ...) }(r.Context())，闭包捕获无效
哪些数据绝对不该塞进 context
所有可变、非请求级、非元数据类内容。一旦开始传业务字段，就等于放弃函数签名契约。
- 订单 ID、用户邮箱、分页参数、API 版本号 —— 这些都该走函数参数，签名即文档
- 大对象（如
[]byte、map[string]interface{}）——context.Value要求 key 和 value 都可比较，传 map 会 panic - 需要修改的值（如“更新用户邮箱后同步到 context”）—— context 不可变，改不了，只能靠上层重传
- 全局配置、服务实例、logger —— 这些属于依赖注入范畴，用 struct 字段或选项模式更清晰
真正该进 context 的只有三类：traceID、userID（只读标识）、request deadline —— 全是不可变、跨 API 边界、与请求生命周期强绑定的元数据。传错地方，问题不会立刻爆发，但会在压测、链路追踪、灰度发布时集中反噬。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
