gin.Context.Copy()不能解决结构体深拷贝问题，因为它只复制上下文元数据（如请求头、路径、方法），不复制通过c.Set()存入的任意结构体，导致原结构体被修改时下游handler读到脏数据。
为什么 gin.Context.Copy() 不能解决结构体深拷贝问题
因为 gin.Context.Copy() 只复制上下文元数据（如请求头、路径、方法），不复制你塞进 c.Set() 或自定义字段里的任意结构体。一旦原结构体被修改，所有引用它的 handler 都会看到脏数据——这不是并发安全的假象，是真实的数据竞争。
常见错误现象：c.Set("user", user) 后在中间件里修改 user.Name，后续 handler 拿到的 c.MustGet("user") 已经变了；或者多个 goroutine 并发写同一个结构体字段，触发 data race 报告。
- 真正需要深拷贝的是你主动存入 context 的结构体，不是 context 本身
-
gin.Context是引用类型，.Copy()不等于“克隆你放进去的东西” - Go 没有语言级深拷贝语法，必须显式处理
用 github.com/jinzhu/copier 做结构体深拷贝最省事
它支持嵌套结构、切片、指针、map，且能跳过零值或忽略字段，比手写递归或 json.Marshal/Unmarshal 更可控、性能更好（无序列化开销）。
使用场景：从 c.MustGet("raw_user") 拿到原始结构体，需在中间件中做校验/脱敏/补全，又不能污染下游 handler 看到的数据。
立即学习“go语言免费学习笔记（深入）”；
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
var raw User
if u, ok := c.MustGet("raw_user").(User); ok {
copier.Copy(&raw, &u) // 注意：目标在前，源在后
}
// 后续可放心改 raw，不影响原始值
raw.Email = sanitize(raw.Email)
c.Set("safe_user", raw)
- 必须传指针给
copier.Copy()，否则只拷贝一层（值传递） - 如果结构体含
time.Time、sql.NullString等特殊类型，加copier.WithDeepCopy(true) - 避免对含 channel、func、unsafe.Pointer 的结构体使用，会 panic
参数传递时用 context.WithValue() 而非 c.Set() 更清晰
c.Set() 是 Gin 封装，底层还是调用 context.WithValue()，但混用会让代码意图模糊。统一用标准库方式，既方便单元测试（直接传 context.Context），也避免 Gin 升级后行为变化带来的隐忧。
示例：把深拷贝后的结构体注入 context，并约束 key 类型为私有类型，防止 key 冲突：
type userCtxKey struct{}
func WithUser(ctx context.Context, u User) context.Context {
return context.WithValue(ctx, userCtxKey{}, u)
}
// 在 handler 中
c.Request = c.Request.WithContext(WithUser(c.Request.Context(), raw))
// 后续 handler 用：
if u, ok := c.Request.Context().Value(userCtxKey{}).(User); ok { ... }
- key 必须是 unexported 类型（如
struct{}），否则不同包可能误用相同字符串 key 导致覆盖 - 不要用
string当 key，这是 Go context 最常见的反模式 -
c.Request.WithContext()返回新 *http.Request，必须重新赋值，否则无效
复杂嵌套结构体慎用 json.Marshal/Unmarshal 深拷贝
虽然看起来“一行搞定”，但它会丢掉未导出字段、丢失方法集、强制转换 time layout、无法处理 NaN 或 inf 浮点数，还引入额外内存分配和 GC 压力。
错误示范：json.Unmarshal(json.Marshal(v), &dst) —— 表面可行，实则埋雷。
- 如果结构体含
sync.Mutex或io.Reader，会 panic 或静默失败 - 时间字段默认按 RFC3339 输出，若原结构体用的是 Unix 时间戳 int64，反序列化后类型不一致
- 嵌套 map[string]interface{} 时，json 会转成 map[string]interface{}，但原始可能是 map[string]CustomType
- 性能差：一次拷贝触发两次内存分配 + GC 扫描，压测时易成瓶颈
真正复杂的结构（比如带自定义 UnmarshalJSON 方法、嵌套 interface{}、动态字段），要么用 copier 配置字段映射，要么手写 Clone() 方法——后者虽啰嗦，但语义最明确、可控性最强。
