context中不能直接传map，因其非线程安全，多goroutine并发读写会触发panic；应改用只读结构体、深拷贝、json.rawmessage序列化或定义具体struct类型，并使用私有未导出类型作key。
Context里不能直接传Map，因为不是线程安全的
Go 的 context.Context 设计上只允许传不可变（或至少不被并发修改）的值。如果你把一个 map[string]interface{} 直接塞进 context.WithValue，多个 goroutine 同时读写这个 map，会触发 panic：fatal error: concurrent map writes。这不是 Context 的锅，是 map 本身不支持并发写 —— 即使你只读不写，只要有人在别处改它，Context 就成了“共享可变状态”的危险通道。
用只读封装 + 深拷贝避免并发风险
真正安全的做法是：不让 map 在 Context 中被原样暴露。常见策略是封装成只读结构体，或每次取值时做深拷贝。比如：
type ReadOnlyMap struct {
data map[string]interface{}
}
func (r ReadOnlyMap) Get(key string) interface{} {
return r.data[key] // 只读访问，不暴露 map 本身
}
// 使用时：
m := map[string]interface{}{"user_id": 123, "role": "admin"}
ctx := context.WithValue(parent, key, ReadOnlyMap{data: m})
注意：ReadOnlyMap 本身不是线程安全的（如果 data 被外部修改仍会出问题），所以更稳妥的是在存入前冻结数据：
- 用
map[string]string这类只含不可变值的类型（避免嵌套指针或 slice） - 或用
json.RawMessage序列化后存，取的时候再json.Unmarshal—— 天然隔离 - 若必须传结构化数据，优先定义具体 struct 类型，而不是泛型 map
为什么不要用 sync.Map 塞进 Context
sync.Map 虽然并发安全，但它不适合放进 Context。原因有三：
- Context 生命周期短，而
sync.Map是为长期存活、高频读写的场景设计的，存在内存泄漏风险（内部桶不会自动收缩） - Context 的
Value方法期望快速返回，sync.Map.Load虽快但多了间接层，且语义错位 —— Context 不是存储服务 - 一旦你开始往 Context 塞
sync.Map，说明你已经在用 Context 做状态管理，这违背了它的初衷：传递截止时间、取消信号和少量请求级元数据
真正该传什么？用 struct 替代 map 更清晰
绝大多数情况下，“需要传 map”其实是需求没厘清。比如想传用户权限，别传 map[string]bool，定义：
type RequestMeta struct {
UserID int64
Role string
Scopes []string
TraceID string
}
ctx := context.WithValue(ctx, metaKey, RequestMeta{UserID: 123, Role: "admin"})
这样既类型安全、可文档化，又杜绝了并发写风险。如果真要动态键值对（如 HTTP header 子集），用 map[string]string 加上明确的拷贝逻辑即可 —— 记住：Context 中的值，应视为只读快照，不是引用句柄。
最常被忽略的一点：Context.Value 的 key 类型必须是可比较的，且推荐用私有未导出类型（如 type ctxKey int）避免冲突；用字符串作 key 在大型项目里极易撞车。
