Context本身不可变，但WithValue传入的map、slice或指针等可变值仍可被下游修改；应传不可变类型、用私有key类型防冲突、避免将Context当作通用状态容器。
Context 本身不可变，但值传递容易误改底层数据
Go 的 context.Context 接口方法（Deadline、Done、Err、Value）全是只读的，所以「传递 Context」本身天然就是只读的。真正的问题是：你用 context.WithValue 塞进去的 value 如果是个 map、slice 或 struct 指针，下游仍可能意外修改它——这不是 Context 的问题，而是你传了可变对象。
常见错误现象：ctx = context.WithValue(parent, key, myMap)，然后 handler 里 myMap["user"] = "admin"，上游逻辑就静默被污染了。
- 永远不要把可变数据（
map、[]string、*MyStruct）直接塞进context.WithValue - 如果必须传结构化数据，定义为不可变类型：用
struct字段全小写 + 不暴露 setter 方法，或用type UserID string这类基础类型别名 - 需要传多个字段时，封装成值语义的 struct，并确保所有字段是不可变类型（避免嵌套指针或 map）
用自定义 key 类型防止 Value 被随意覆盖
用字符串当 key（如 "user_id"）会导致不同包之间 key 冲突，而且无法控制谁往 Context 里写什么。这不是“只读”问题，但直接影响数据可靠性。
正确做法是定义私有未导出类型作为 key：
立即学习“go语言免费学习笔记（深入）”；
type ctxKey string const userKey ctxKey = "user" // 其他包无法构造 ctxKey 类型，也就无法调用 context.WithValue(ctx, userKey, ...)
这样即使别人拿到你的 Context，也拿不到合法 key，无法覆盖或读取该字段——比文档约定更可靠。
- key 类型必须是未导出的（首字母小写），否则其他包能 new 出同类型实例
- 不要用
int或uintptr当 key，易冲突且无类型安全 - 如果需跨包共享 key，提供导出的 getter 函数（如
func UserFromCtx(ctx context.Context) *User），而不是暴露 key
Value 里的数据该不该深拷贝？看场景
不是所有情况都要深拷贝，但得清楚代价和风险。比如你传一个 time.Time，它是值类型，安全；传一个 *http.Request，那下游调 req.Header.Set 就会影响上游。
- 基础类型（
int、string、time.Time）、小 struct、sync.Map实例 —— 可直接传，无需拷贝 - map/slice/指针类型 —— 必须拷贝：传
map[string]string就用copyMap()包一层；传*Config就改用Config值类型或提供Clone()方法 - 性能敏感路径（如中间件高频调用）慎用深拷贝，优先重构为只传必要字段，或用只读接口包装（如
type ReadOnlyConfig interface{ GetTimeout() time.Duration }）
别把 Context 当成通用状态容器
很多人把 Context 当成“跨函数传参的万能兜底”，塞日志字段、配置、DB 连接……这违背 Context 设计初衷，也放大了只读性失控的风险。
Context 应只承载请求生命周期内**与取消、超时、认证上下文强相关**的数据。其他东西该走参数就走参数，该走依赖注入就走依赖注入。
- 用户 ID、trace ID、权限角色 —— 合理放进 Context
- 数据库连接、缓存客户端、配置对象 —— 应通过函数参数、struct 字段或依赖注入容器传入
- 日志字段（如
reqID）可以放，但别放整个log.Logger实例（它通常带可变的 fields map）
最常被忽略的一点：Context.Value 查找是线性遍历链表，大量嵌套 WithValue 会拖慢性能，而你以为的“只读安全”可能正掩盖着低效和耦合。
