安全脱敏http请求需复制而非修改原始数据：统一解析req.url.rawquery和req.postform，用配置化敏感键名对value局部掩码；json用sjson局部替换；必处理authorization等header；覆盖所有入口确保无遗漏。
HTTP中间件里怎么安全地脱敏 req.URL.Query() 和 req.PostForm
直接遍历并修改原始 url.Values 是危险的——Go 的 req.URL.Query() 返回的是只读副本，而 req.ParseForm() 后的 req.PostForm 虽可写，但改了也影响后续 handler 逻辑。真正安全的做法是复制一份、脱敏后再用于日志，不碰原始请求数据。
- 敏感键名（如
password、token、id_card）建议统一配置成 map 或 slice，避免硬编码在日志逻辑里 - 对 value 做简单掩码（如保留前2位+星号）比全量清空更利于问题排查，比如
"abc123"→"ab****" - 注意 URL 查询参数可能出现在
req.URL.RawQuery里，不能只处理req.URL.Query()；POST 表单还要区分application/x-www-form-urlencoded和multipart/form-data，后者需跳过文件字段
为什么 log.Printf 直接打 req.Form 会漏掉敏感内容
req.Form 是惰性初始化的：没调用 req.ParseForm() 前它是空的；调用了，它才合并 URL.Query() 和 PostForm。但很多 handler 没显式调用它，尤其用 json 或 protobuf body 的接口——这时候 req.Form 为空，日志就完全看不到 query 参数，更别说脱敏了。
- 正确做法是统一从
req.URL.RawQuery解析查询参数，再和req.PostForm（已 parse 过）分别处理 - 如果 handler 用
io.ReadAll(req.Body)提前消费了 body，req.ParseForm()会失败，PostForm为空，必须自己解析 raw body - 别依赖
req.FormValue("xxx")做脱敏判断——它只返回第一个值，且无法区分来源（query 还是 form）
JSON 请求体里的敏感字段怎么在不破坏结构前提下脱敏
直接 json.Unmarshal 再 json.Marshal 成本高，还可能因 struct tag 不一致导致字段丢失。更轻量的方式是用 json.RawMessage 做局部解析，或用第三方库如 gjson / sjson 定位并替换。
- 如果已知敏感字段路径（如
.user.password），用sjson.SetBytes替换比反序列化整个 body 更快 - 注意嵌套数组场景：
[{"pwd":"123"},{"pwd":"456"}]需要通配匹配，sjson支持.*.pwd语法 - 脱敏后 JSON 字节数可能变化（如
"123"→"**"），若后续要验签或计算 content-length，得用脱敏前原始 body
审计日志里漏掉 Authorization 头是常见低级错误
很多人只扫 query 和 form，忘了 header。而 Authorization 通常带 Bearer Token 或 Basic 凭据，是最高危字段之一。它不在 req.URL 或 req.PostForm 里，必须单独提取。
立即学习“go语言免费学习笔记（深入）”；
- 检查
req.Header.Get("Authorization")，按 scheme 分类处理：Bearer 后的 token 全掩码，Basic 后的 base64 字符串解码后再掩码用户密码部分 - 注意有些网关会把真实 auth 头转成
X-Forwarded-Authorization或其他自定义头，审计规则得覆盖常见变体 - 别用
strings.Contains粗暴过滤 header key——大小写不敏感，且 Go 的Headermap key 是规范化的（Authorization而非authorization），直接Get更稳
最麻烦的不是怎么脱敏，而是怎么确保所有入口（HTTP/HTTPS/gRPC-Gateway/健康检查端点）都走同一套逻辑。中间件容易漏掉静态文件路由或 panic 恢复前的日志，这些地方一旦出问题，敏感信息就裸奔了。
