Go中数据脱敏不能依赖中间件自动识别敏感字段，必须显式声明struct tag、控制序列化入口、包装ResponseWriter；真正可控的是json.Marshaler接口实现，且日志、gRPC等各出口需独立脱敏。
Go 里用中间件封装数据脱敏，本质是徒劳的——除非你提前放弃“自动识别敏感字段”这个幻想，并接受必须显式声明、控制序列化入口、包装 ResponseWriter 这三件事。
中间件无法自动识别哪些字段要脱敏
gin 或 http.Handler 中间件拿到的只是 *http.Request 和 http.ResponseWriter，没有结构体字段语义。它不知道 User.Phone 是手机号，也不知道 Order.IDCard 是身份证号。
- 常见错误：在中间件里对所有
string字段统一替换为"***"→ 昵称、城市名、商品标题全被误杀 - 可行路径只有两条：
sensitive:"phone"这类 struct tag 标记，或统一响应结构（如Response{Data: interface{}}，只处理Data字段） - 若用反射扫描，必须限定白名单类型（如
*User、[]Order），且无法安全处理interface{}或匿名嵌套结构体
HTTP 响应脱敏必须替换 ResponseWriter，不能等 c.Next() 后读 body
gin 默认不缓存响应体，c.Writer 一旦调用 WriteHeader 或首次 Write，状态码和字节就直接推到 TCP 连接，中间件里再也拿不到原始 JSON。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 错误做法：
c.Next()后试图读c.Writer.Body—— gin 根本不暴露该字段；即使有，也早已 flush - 正确做法：在 handler 执行前，用自定义
ResponseWriter替换c.Writer，重写Write([]byte)和WriteHeader(int) - 仅对
Content-Type: application/json做处理，其他类型（如text/html）直通，避免破坏静态资源或下载流 - 解析 JSON 时推荐用
json.Decoder.Token()流式匹配 key 路径（如user.phone），而非全量json.Unmarshal，减少内存与 GC 压力
真正可控的脱敏入口是 json.Marshaler 接口，不是中间件
所有“字符串替换”“正则扫 JSON 字节流”“gzip 解压再改内容”的做法，在真实服务中要么漏字段、要么破格式、要么 panic。上线即翻车。
立即学习“go语言免费学习笔记（深入）”；
- 必须实现指针接收器：
func (u *User) MarshalJSON() ([]byte, error)，否则无法处理嵌套字段（如u.Profile.Phone）或 nil 指针 - 防递归关键：定义别名类型
type Alias User，再用(*Alias)(u)转换，避免MarshalJSON无限调用自身 - 权限判断不能塞进方法签名（
json.Marshal不传context.Context），得靠闭包捕获，比如redactEnabled := isRedactEnabled(ctx)后在闭包内使用 - 脱敏值禁用空字符串：若字段带
json:",omitempty"，脱敏后为空就会整个字段消失；建议用"[REDACTED]"或固定掩码如"*** **** ***"
最易被忽略的一点：日志、HTTP 响应、gRPC 返回、panic 堆栈这些出口，脱敏逻辑必须各自收口，不能指望一个中间件覆盖全部。尤其日志脱敏，必须在 zap.Object 的 MarshalLogObject 方法里做，而不是在中间件里对 map[string]interface{} 递归扫——性能差，还容易误伤非敏感字段。
