log.Printf 直接打印敏感字段会导致明文残留，正确做法是在日志结构化前用 slog.LogValuer 接口动态脱敏，如定义 SensitiveToken 类型实现 LogValue() 返回 "[REDACTED]"。
为什么 log.Printf 直接打敏感字段会出问题
Go 标准库日志本身不识别“敏感字段”，log.Printf 或 fmt.Sprintf 一旦拼入 user.Password、token、authCode 等变量，原始值就固化进字符串，后续无法剥离。哪怕你用中间件统一处理日志输出，此时已晚——敏感信息早已在内存或 I/O 缓冲区里明文存在过。
真正可行的路径是：在日志结构化前、字段尚未被格式化成字符串时，就对值做动态替换。这意味着必须放弃直接传原始 struct 或 map，改用可拦截的字段访问方式。
- 别把整个
user对象丢给logrus.WithFields—— 它不会递归检查 key 名是否含password - 避免在
fmt.Sprintf("user: %+v", user)中格式化结构体，%+v会完整展开所有字段 - 不要依赖日志后端（如 Loki、ELK）的正则脱敏——延迟高、漏脱风险大、且审计不认可“日志落地后再擦除”
用 log/slog 的 LogValuer 接口做运行时遮蔽
Go 1.21+ 的 slog 支持 LogValuer 接口，它会在每次日志输出前调用 LogValue() 方法，让你有机会返回脱敏后的值。这是目前最轻量、最可控的动态过滤方式。
例如定义一个带遮蔽逻辑的 token 类型：
立即学习“go语言免费学习笔记（深入）”；
type SensitiveToken string
func (t SensitiveToken) LogValue() slog.Value {
return slog.StringValue("[REDACTED]")
}
然后在构造日志时显式使用该类型：
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
slog.Info("login success", "token", SensitiveToken(user.Token))
- 只有显式声明为
LogValuer类型的字段才会触发遮蔽，不会误伤同名普通字符串 - 支持嵌套：如果结构体字段是
LogValuer类型，slog会自动调用其LogValue() - 注意：不能对指针类型（如
*string）直接实现LogValuer，需包装为新类型而非指针接收者
在 Gin/Gin middleware 中拦截并重写 context 日志字段
Gin 默认不集成结构化日志，但多数团队会用 gin-contrib/zap 或自定义 slog middleware。关键不是“加日志”，而是“加一层字段预处理”。
典型错误是这样写：
c.Set("user", user) // user 是原始 struct
slog.Info("request", "user", c.MustGet("user"))
正确做法是提前封装敏感字段：
type SafeUser struct {
ID int
Email string
Password SensitiveString // 自定义类型，实现 LogValuer
}
func (h *Handler) Login(c *gin.Context) {
user := SafeUser{
ID: dbUser.ID,
Email: dbUser.Email,
Password: SensitiveString(dbUser.Password),
}
slog.Info("login", "user", user)
}
- 不要试图在 middleware 里用反射遍历所有
c.Keys并模糊匹配字段名（如包含pass、token），反射开销大且易漏判 - 若必须动态注入字段（如统一 traceID、userID），可用
slog.With("trace_id", c.GetString("X-Trace-ID"))，再链式调用.Info()，确保每个字段都经手可控类型 - Gin 的
c.Request.URL.Query()和c.PostForm需手动过滤，slog不会自动处理 request body
第三方库如 zerolog 的 Hook 机制慎用
zerolog 提供 Hook 接口，在日志事件生成后、写入前介入。表面看很适合脱敏，但实际有严重隐患：
它的 Run() 方法接收的是已序列化的 zerolog.Event，字段值多为 interface{}，而 Go 的 interface{} 在 runtime 无法安全反解结构体字段名——你只能靠 fmt.Sprint(v) 转字符串再正则替换，这又回到了“字符串级脱敏”的老路，可能误删（如把 password_reset_token 替成 [REDACTED]_reset_token）或漏删（嵌套 map 深层字段）。
- 除非你完全控制所有日志调用点，并约定所有敏感字段都用固定 key（如统一叫
secret），否则Hook不可靠 -
zerolog.Encoder的EncodeInterface可定制，但需自己实现 JSON encoder 分支逻辑，复杂度远超LogValuer - 如果你已在用
zap，它的Field类型不支持运行时重写，只能靠Core层拦截，同样面临字段名不可知问题
动态遮蔽的本质不是“找词替换”，而是“控制源头赋值”。越靠近字段定义和日志调用点做类型约束，越不容易漏、越容易测试、越能通过静态检查发现裸用敏感字段的问题。
