go语言 Ctx:「错误三：在 Context 中存储可变值」

context.WithValue 看起来像是一个很方便的数据传递方式。对于合适的数据，它确实方便。

但很多人忽略了一个关键约束：放进 context 的值应该是不可变的。

如果你把一个可变指针放进 context，然后通过 context 取出来修改，那基本就是在等 data race 发生。

如果多个 goroutine 共享同一个 context ，并且都调用 MetricsFromContext 修改这个结构体，就会产生数据竞争。

Go 的 race detector 可以在测试中发现这类问题，但前提是你的测试真的覆盖到了并发路径。

如果你确实需要并发安全的修改，那么这个 value 自身应该包含锁：

对于简单计数器，更好的做法是使用 atomic：

更大的原则是：

如果 context 中的某个值需要被修改，那么这个修改行为必须是显式且线程安全的，而不是依赖约定。

辅助理解：

1.context 中的某个值需要被修改 就是前面例子：从 ctx 取出*RequestMetrics，要修改它里面的字段。

2.显式

❌坏写法（隐式）：

m := MetricsFromContext(ctx)
m.DBQueries++ // 直接裸写 ++，随手改结构体字段

这种修改是偷偷摸摸 的，看代码第一眼不知道这行会修改共享对象，全靠程序员口头约定："大家注意，这个对象多协程不要乱改"。👉这就是依赖约定。

✅显式写法：把修改封装成方法，调用方法去改

m.RecordDBQuery() // 一看就知道：这里要做修改操作

修改动作不再是普通++，而是调用一个专门的函数，代码阅读者一眼识别：这里会变更状态。

3.线程安全

方法内部必须保护并发：sync.Mutex上锁 / atomic原子类型。 不能裸操作普通 int 字段。

4.不要依赖约定

依赖约定：团队口头、文档写一句 "警告，这个 metrics 不要直接改字段！"

人的约定是不可靠的：

• 新来的同事没看文档；
• 过几个月自己写代码忘记这个坑；
• 代码重构，随手写一行m.DBQueries++，直接引入 data‑race。

靠人自觉约束，迟早会翻车。要把安全约束写进代码本身，而不是靠人的记性。

5.正反对比

❌反面：依赖约定（危险）

✅正面：显式 + 线程安全（符合这条原则）

使用：

就算有人想乱改，他也要主动写m.DBQueries++；只要团队代码规范不允许直接访问，错误写法很容易被 code review 抓到。更好做法：字段小写不导出，外部包完全访问不到。

type RequestMetrics struct {
	mu        sync.Mutex
	dbQueries int // 小写，外部包无法直接修改！只能调用方法
}

一句话总结这条大原则

不要指望所有人记住 "不要直接改 ctx 拿出来的对象" 这种口头约定。 如果一定要往 ctx 里面放要修改的对象：

1. 修改操作封装成专门的方法调用（显式）
2. 方法内部用锁 /atomic 保证并发安全
3. 最好结构体字段不对外暴露，从语法层面阻止裸修改。
   终极最佳实践：可变对象干脆不要塞 context，直接函数参数传递，从根源避开整套坑