context.withvalue 的键必须是私有类型，如未导出空结构体 useridkey，避免字符串键导致的命名冲突与拼写错误；context 不可跨网络序列化，需手动提取字段通过 header 或 metadata 透传；敏感数据严禁放入 context 或 header。
context.WithValue 的键必须是私有类型，不能用 string
直接用 "user_id" 这样的字符串当 key，是 Go 微服务里最常见、也最危险的写法。不同包可能无意中复用相同字符串，导致值被覆盖或读错；拼写错误（比如 "user_id" vs "userid"）在编译期完全无法发现，只能等运行时 panic。
正确做法是定义一个未导出的空结构体类型作为 key：
type userIDKey struct{}
然后统一用这个类型存取：
ctx = context.WithValue(ctx, userIDKey{}, userID)if id, ok := ctx.Value(userIDKey{}).(string); ok { ... }
这样既避免了全局命名冲突，又把类型约束带进了编译期——如果传入非 string 类型，断言会失败，但至少不会静默覆盖。
跨 HTTP 服务传递 context 数据，只透传字段，不传 context 对象本身
context.Context 本身不能跨网络边界。你不能把整个 ctx 序列化进 JSON body 或 gRPC payload 里再反序列化回来——它内部包含 channel、timer 等不可序列化字段，且取消信号、deadline 语义会彻底丢失。
必须手动提取需要透传的字段，通过 HTTP Header 或 gRPC Metadata 传递：
- HTTP 场景：用
X-Request-ID、X-Trace-ID、X-User-ID等标准 header 键 - gRPC 场景：用
metadata.Pairs("x-user-id", userID)构建metadata.MD，再通过metadata.NewOutgoingContext()注入 - 下游服务收到后，用对应方式读取并构造新
ctx：context.WithValue(parentCtx, userIDKey{}, userID)
切记：Header 和 Metadata 只能传 string 或 []string，别塞 struct、token 原文或 session 对象。
ctxport 库能解决类型断言和键冲突，但不替代 context 核心语义
ctxport 的价值在于把 ctx.Value(key) 这种易错操作，变成类型安全的函数调用，比如 ctxport.GetUserID(ctx) 返回 string 而不是 interface{}。它底层还是基于标准 context.Context，只是加了一层泛型封装。
但它不处理 deadline、cancel、timeout 这些核心控制流能力——这些仍得靠 context.WithCancel、context.WithTimeout 来管理。
所以实际用法是组合使用：
- 用
context.WithTimeout控制超时 - 用
ctxport.SetUserID安全存用户 ID - 中间件或 handler 里直接调
ctxport.GetUserID(ctx)，不用再写断言
它适合已踩过原生 WithValue 坑的团队，升级成本低，但别指望它帮你自动透传或加密。
敏感数据绝不能进 context，也不该进 HTTP Header
context 是请求生命周期的“元数据通道”，不是临时存储区。把 token 原文、DB 连接、用户密码哈希甚至完整 *User struct 塞进去，会导致内存泄漏（context 生命周期可能比 goroutine 更长）、GC 压力上升，还可能意外泄露到日志或监控系统。
更危险的是，如果把这些数据写进 HTTP Header 透传，等于把敏感信息明文暴露在网络链路上——哪怕走 HTTPS，也增加了代理、网关、负载均衡器侧的泄露风险。
真正该进 context 的只有：
- 只读、轻量、跨中间件必需的标识类字段（
request_id、trace_id、timezone） - 业务标志位（
is_admin、tenant_id），且需确保是经过鉴权后提取的干净值
其他一切，走依赖注入、本地缓存或数据库查，别图省事往 context 里堆。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
