context.withvalue传值本身线程安全，但90%误用源于key类型不唯一、断言不严谨或滥用为参数容器；key必须用未导出私有类型（如type useridkey struct{}），取值须用双返回值断言，且仅存不可变元数据。
直接说结论：用 context.WithValue 传数据本身是线程安全的，但“安全”不等于“正确”——90% 的误用来自 key 类型不唯一、值类型断言不严谨、或把 context 当参数容器滥用。
为什么 WithValue 的 key 必须是自定义类型
Go 的 context.Value 接口接收 interface{} 类型的 key，但底层用 == 比较 key 是否相等。如果用字符串或 int 作 key：
- 不同包里写
"user_id"，会被当成两个 key，导致取不到值 - 多个地方用
int(1)当 key，一旦某处改了数字，整条链就断了 - 编译器完全无法检查 key 是否拼错或重复
正确做法是定义私有类型：
type userIDKey struct{}
ctx := context.WithValue(parent, userIDKey{}, 123)
// 取值时必须用同一个类型
if id, ok := ctx.Value(userIDKey{}).(int); ok {
// 安全
}
取值时类型断言失败怎么办
ctx.Value(key) 返回 interface{}，直接强制类型断言（如 .(*User)）会在 key 不存在或类型不符时 panic。这不是 bug，是设计使然 —— Go 不提供运行时类型保障。
- 永远用双返回值形式：
v, ok := ctx.Value(key).(MyType) - 不要在中间件里假设值一定存在；handler 应校验
ok，缺失时返回 400 或 fallback - 避免嵌套断言，比如
ctx.Value(k).(*User).Profile.Name—— 任一环节 nil 都 panic
哪些数据不该塞进 context
Context 不是通用参数包。它只承载请求生命周期内、跨 goroutine 共享的元数据（metadata），不是业务实体或配置。
- ✅ 合适：traceID、userID、timezone、abTestGroup、shardingHint
- ❌ 危险：*sql.DB、*http.Client、struct{} 大对象、函数闭包、error 实例
- ⚠️ 警惕：传递指针时，若原值被上游修改，下游看到的就是脏数据 —— context 不做 deep copy
为什么 ctxport 这类库值得考虑
当项目中 WithValue 调用超过 20 处，或团队超过 5 人时，手写 key 类型和重复断言的成本会急剧上升。此时 ctxport 提供的类型安全封装就显出价值：
- 每个 key 是一个带方法的类型，
Get(ctx)直接返回强类型值，无 panic 风险 - key 定义集中管理，IDE 可跳转、可搜索、可重构
- 零运行时开销，编译期检查替代运行时 panic
- 不替换
context.Context，只是在其之上加了一层薄抽象
真正容易被忽略的点是：context 的“安全”从来不在并发层面（它本就是并发安全的），而在于**使用契约是否被所有人遵守**。一个没定义 key 类型的 PR，可能让整个链路的 traceID 丢失三天才被发现。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
