直接用 fmt.printf 打印请求参数会泄露敏感字段，因为 go 标准库不识别敏感概念，结构体字段被 %+v 或 json.marshal 输出时原始值裸奔；中间件如 gin 默认全量打印 query/form，无脱敏入口。
为什么直接用 fmt.Printf 打印请求参数会泄露敏感字段
微服务日志里常出现 password、id_card、phone 这类字段，但 Go 的标准日志库和 fmt 包完全不识别“敏感”概念。只要结构体字段被 %+v 或 json.Marshal 输出，原始值就裸奔了。更麻烦的是，很多中间件（比如 Gin 的 Logger()）默认把整个 c.Request.URL.Query() 或 c.PostForm 倒进日志——根本没留脱敏入口。
用结构体标签 + 自定义 String() 方法做字段级脱敏
最轻量、最可控的方式是让敏感字段自己决定怎么显示。Go 允许为任意类型实现 String() 方法，日志打印时会自动调用它。配合结构体标签（如 json:"password,omitempty" redact:"true"），能兼顾序列化和脱敏逻辑。
实操建议：
- 对含敏感字段的结构体（如
UserLoginReq），不直接log.Printf("%+v", req)，而是为该类型实现String()方法，在其中手动替换敏感字段为"***" - 避免在
String()里调用json.Marshal—— 容易触发无限递归（如果字段本身又含同类型嵌套） - 别依赖第三方“自动扫描 struct tag 脱敏”的库（比如某些
redact包），它们往往只处理jsontag，对form、query、header无能为力
示例：
type UserLoginReq struct {
Username string `json:"username"`
Password string `json:"password" redact:"true"`
}
func (r UserLoginReq) String() string {
return fmt.Sprintf("UserLoginReq{Username:%q, Password:***}", r.Username)
}
HTTP 中间件中拦截并重写日志上下文
Gin / Echo / Fiber 等框架的日志中间件默认不提供修改日志内容的钩子。强行 patch 框架源码或 monkey patch log.Print 风险高、维护难。正确做法是：在中间件里提前提取并脱敏关键数据，再注入到 context 或自定义日志字段中。
实操建议：
- 在路由中间件里用
c.ShouldBindQuery()或c.ShouldBindJSON()解析请求，立即对解析出的 struct 调用脱敏方法（如上面的String()），结果存入c.Set("safe_log_fields", ...) - 用
log.WithFields()（如 logrus）或zerolog.Ctx(c.Request.Context())写日志，而非拼接字符串 —— 这样能确保脱敏后字段单独输出，不会被其他未脱敏字段污染 - 特别注意
Content-Type: application/x-www-form-urlencoded场景：Gin 的c.PostForm("password")返回原始字符串，必须显式判断 key 名并替换
全局日志处理器里过滤已知敏感键名
不是所有请求都走结构体绑定；有些直接读 body 字节流、有些用 map[string]string 存 query。这时需要兜底方案：在最终写入日志前，对日志消息做一次键名匹配脱敏。
实操建议：
- 不要正则全局替换
"138****1234"→"***"，这会误伤正常数字字段（比如订单号、金额） - 只匹配明确的键路径：如 JSON 日志中
"user.password"、"data.id_card"，或 URL 查询串中的"&password="、"&card_no=" - 用
strings.ReplaceAll替换值部分，而不是删掉整个键值对 —— 否则日志格式会被破坏，影响 ELK 解析 - 性能敏感服务慎用此法：每次日志都要做字符串扫描，QPS 高时 CPU 开销明显
容易被忽略的一点：环境变量里的 DB_PASSWORD、REDIS_AUTH 也属于敏感日志源，启动时若用 log.Printf("config: %+v", cfg) 会直接打出来 —— 这类配置结构体必须统一实现 String()，不能靠运行时过滤补救。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
