不能在 Gin 中间件里直接对 ctx.Request.Body 做哈希脱敏，因为 Request.Body 是一次性可读流，中间件读取后会导致后续 handler 读取为空，引发 JSON 解析失败等错误；正确做法是通过 c.Set()/c.Get() 跨中间件传递敏感字段原始值，在响应阶段统一哈希脱敏。
为什么不能在 Gin 中间件里直接对 ctx.Request.Body 做哈希脱敏
因为 ctx.Request.Body 是一次性可读流，中间件读取后，后续 handler 就会读到空内容，导致业务逻辑解析失败（比如 c.ShouldBindJSON() 报 invalid character）。这不是 bug，是 Go HTTP 标准库的设计约束。
常见错误现象：
- 脱敏后接口返回 400，日志显示 JSON 解析失败
- Postman 能发通，但前端 Axios 报错：”Unexpected end of JSON input“
-
c.GetRawData()在中间件中调用一次后，c.ShouldBind()永远失败
可行路径只有一条：不碰原始 Body，改在响应生成前或字段输出时做处理。中间件能安全操作的，是 ctx 上挂载的数据或即将写出的响应体。
用 c.Set() + c.Get() 在中间件中预埋脱敏规则
Gin 的 gin.Context 支持跨中间件共享数据，适合把脱敏策略和原始值解耦。例如，你希望对 id_card 字段做 SHA256 哈希，但又不想让 handler 知道具体算法 —— 就让它把原始值存进 c.Set("sensitive:id_card", rawValue)，由下游中间件统一处理。
实操建议：
- 定义统一键名前缀，如
sensitive:，避免和业务 key 冲突 - 只在必要字段上
c.Set()，不要全量 dump 请求体，否则内存压力大 - 哈希计算建议用
sha256.Sum256([]byte(rawValue)).Hex()，不加 salt（因需一致性），但注意：若原始值极短（如单个手机号），应拼接固定盐值防彩虹表
示例片段：
func HashSensitiveFields() gin.HandlerFunc {
return func(c *gin.Context) {
// 从绑定后的结构体中提取敏感字段（需 handler 已执行 ShouldBind）
if user, ok := c.Get("user"); ok {
if u, ok := user.(map[string]interface{}); ok {
if idCard, ok := u["id_card"].(string); ok {
hash := fmt.Sprintf("%x", sha256.Sum256([]byte("PIPL_SALT_"+idCard)))
c.Set("sensitive:id_card", hash)
}
}
}
c.Next()
}
}
响应阶段用 c.Render() 替换敏感字段值
真正做哈希替换的时机，应在响应即将写出前，用自定义 render 或拦截 c.JSON()。Gin 不允许直接重写 c.JSON，但可通过包装响应 writer 实现。
关键点：
- 必须用
gin.ResponseWriter包装原始 writer，才能捕获并修改响应体 - 仅对
Content-Type: application/json响应做处理，其他类型（如 HTML、文件）跳过 - 哈希后的字段长度固定（如 SHA256 是 64 字符），要确保前端能兼容该长度，避免 UI 错位
简单做法：在最终中间件中，用 json.Unmarshal 解析已生成的响应数据，遍历 key 匹配 id_card、phone 等字段，替换成对应 c.Get("sensitive:xxx") 的值，再 json.Marshal 写出。
哈希脱敏与掩码脱敏的适用边界必须分清
哈希不是万能替代方案。如果业务需要「相同身份证号始终生成相同哈希值」，那没问题；但如果要求「同一人不同请求的哈希值不同」（防追踪），就得引入随机 nonce —— 这就违背了哈希脱敏的一致性原则，实际应改用加密脱敏（如 AES-GCM）。
容易被忽略的细节：
- 哈希结果不可逆，但若原始值空间小（如 11 位手机号），暴力穷举可在秒级完成，必须加盐且盐值保密
- 数据库索引字段若依赖哈希值查询，需确认是否支持前缀索引或函数索引（MySQL 8.0+ 支持
CREATE INDEX ON t ((SHA2(id_card,256)))） - Gin 中间件链中，
c.Abort()后不会执行后续中间件，但已c.Set()的值仍存在，要注意清理或标注状态
医疗系统尤其要注意：PIPL 第 73 条明确禁止对患者身份信息做“可批量反推”的哈希，除非配合差分隐私噪声。纯 SHA256 对身份证号哈希，属于高风险操作。
