go中间件无法自动识别敏感字段，必须通过struct tag标记或统一响应包装结构显式声明；加盐需用kms/vault管理密钥，gin中推荐自定义render实现精准脱敏。
Go 中间件无法自动识别“敏感字段”——必须显式声明或约定规则，否则加盐、屏蔽都无从谈起。
敏感字段必须提前约定，不能靠反射猜
Go 的 json.Marshal 和 http.ResponseWriter 不会暴露结构体字段语义。中间件拿到的只是已序列化的 []byte 或未写入的原始结构体指针，没有上下文就无法判断哪个字段是密码、手机号或身份证号。
- 常见错误：在中间件里对所有
string字段统一加盐或替换成***—— 导致昵称、地址、商品名全被误杀 - 可行方案只有两种：
struct tag标记（如json:"phone,omitempty" sensitive:"salt"）或统一响应包装结构（如所有 API 返回Response{Data: ..., Code: ...}，只处理Data字段） - 若用
reflect动态扫描，需额外维护白名单类型（如*User、[]Order），且无法安全处理嵌套匿名结构体或 interface{}
加盐不能在 ResponseWriter.Write 之后做
HTTP 响应头（包括 Content-Length）通常在第一次 Write 调用时自动发送。若中间件先调用 next.ServeHTTP，再试图读取并重写响应体，会导致 http: multiple response.WriteHeader calls 错误。
- 正确做法：用自定义
responseWriter包装原http.ResponseWriter，拦截Write和WriteHeader调用 - 关键点：缓存响应体到
bytes.Buffer，等WriteHeader和所有Write完成后再解析 JSON、脱敏、加盐，最后一次性Write出去 - 注意：必须检查
Content-Type是否为application/json，避免误处理 HTML 或二进制流
Gin 框架下推荐用 c.Render + 自定义 Render 实现
Gin 的 *gin.Context 不直接暴露 ResponseWriter 写入过程，但提供 c.Render 接口。与其劫持底层 writer，不如替换 gin.Render 行为。
- 定义新 struct：
type SensitiveJSON struct{ Data interface{} }，实现Render(http.ResponseWriter)方法 - 在该方法内调用
json.Marshal→ 扫描Data中带sensitivetag 的字段 → 对值做 SHA256+salt 或掩码（如手机号留前3后4）→ 再写入 - 业务 handler 改为：
c.Render(200, SensitiveJSON{Data: user})，而非c.JSON(200, user) - 优势：不侵入中间件链，不干扰其他中间件（如日志、CORS），且能精准控制作用域
加盐密钥绝不能硬编码或写死在代码里
加盐不是加密，但 salt 若泄露，攻击者可批量反查原始值（尤其手机号、邮箱等低熵字段）。生产环境必须隔离管理。
- 禁止：
const salt = "my_secret_123"或从os.Getenv("SALT")直接读取明文 - 推荐：用 KMS（如 AWS KMS、阿里云 KMS）解密获取运行时 salt；或通过 Vault 动态下发，配合 TTL 与审计日志
- 退而求其次：将 salt 存于配置中心（如 Nacos、Consul），启动时拉取并内存持有，禁止落盘、禁止日志打印
- 额外提醒：同一 salt 不可用于多租户场景——租户隔离需分 salt，否则 A 租户可借 B 租户数据撞库
真正难的不是写一个能加盐的中间件，而是让每个业务开发者清楚地知道“这个字段要加盐”“那个字段要掩码”，并在结构体上准确打标。没有规范约束的自动化，只会把问题藏得更深。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
