gin.Default()不能直接用于审计，因其默认Logger和Recovery仅记录基础信息（状态码、路径、耗时），缺失请求体、响应体、Header等完整上下文；审计需可追溯、可还原、可合规，必须自定义中间件控制采集粒度与时机，并通过缓冲Body、包装ResponseWriter等方式安全捕获敏感数据。
为什么 Gin 的 gin.Default() 不能直接用于审计？
因为 gin.Default() 默认启用了 gin.Logger() 和 gin.Recovery()，但它们只记录基础信息（如状态码、耗时、路径），不包含请求体、响应体、Header、查询参数等完整上下文。审计要求可追溯、可还原、可合规，必须自己控制日志粒度和数据采集时机。
常见错误是直接在中间件里读 c.Request.Body —— 这会导致后续 handler 读不到 body，因为 http.Request.Body 是单次读取流。
- 必须用
c.Request.Body的副本（如io.ReadCloser）做缓冲，再用httputil.DumpRequestOut或手动复制 - 响应体审计更麻烦：Gin 的
c.Writer是接口，需包装成自定义ResponseWriter拦截写入 - 敏感字段（如密码、token）必须白名单过滤，不能靠“事后脱敏”，否则审计日志本身就成了泄露源
如何安全地捕获请求 Body 而不破坏后续处理？
核心是用 bytes.Buffer 缓存原始 body，并替换 c.Request.Body 为可重复读的 io.NopCloser。
func auditRequestBody(c *gin.Context) {
if c.Request.Body == nil {
return
}
body, _ := io.ReadAll(c.Request.Body)
c.Request.Body.Close()
// 保存原始 body 供审计用
c.Set("audit_request_body", string(body))
// 重置 Body，供下游 handler 正常读取
c.Request.Body = io.NopCloser(bytes.NewBuffer(body))
}
注意：io.ReadAll 会消耗整个 body，所以必须在所有中间件（尤其是绑定前）尽早执行；如果用了 c.ShouldBindJSON() 等，它内部也会读 body，顺序错乱就会丢数据。
立即学习“go语言免费学习笔记（深入）”；
- 这个函数必须放在所有依赖 body 的中间件之前（比如
gin.Bind、c.PostForm） - 大文件上传场景下，不要无条件缓存全部 body，应限制大小（如
if len(body) > 1024*1024 { ... }） - 二进制内容（如图片、PDF）建议只记录长度和 MIME 类型，不存原始 bytes
怎样拦截并记录响应 Body 和 Header？
Gin 的 c.Writer 是 gin.ResponseWriter 接口，需用包装器劫持 Write() 和 WriteHeader() 调用。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
type auditWriter struct {
gin.ResponseWriter
bodyBytes *bytes.Buffer
}
func (w *auditWriter) Write(b []byte) (int, error) {
w.bodyBytes.Write(b)
return w.ResponseWriter.Write(b)
}
func (w *auditWriter) WriteHeader(code int) {
w.ResponseWriter.WriteHeader(code)
}
然后在中间件中替换 writer：
w := &auditWriter{
ResponseWriter: c.Writer,
bodyBytes: &bytes.Buffer{},
}
c.Writer = w
响应结束时（c.Next() 后），从 w.bodyBytes.String() 获取响应体。但要注意：
- 如果 handler 调用了
c.Render()或c.JSON()，它们可能提前写 header，所以必须在c.Next()前完成 writer 替换 - gzip 压缩开启时，
Write()写入的是压缩后数据，审计日志里看到的是乱码 —— 应该在 gzip 中间件之后插入审计，或禁用压缩做审计 - HTTP/2 流式响应（如 SSE）无法完整捕获 body，只能记录首块或放弃 body 审计
审计日志该存到哪里？性能和可靠性怎么平衡？
本地文件写入快但不可靠（进程崩溃丢失、磁盘满导致阻塞请求）；发 Kafka 或 Loki 可靠但引入额外依赖和延迟。实际选型取决于审计等级：
- 合规强要求（如金融、医疗）：必须异步落盘 + 本地+远程双写，用
chan做缓冲队列，避免阻塞 HTTP 请求 - 调试/灰度环境：直接写
logrus.WithFields()到文件，加rotate控制大小 - 千万级 QPS 场景：只记录异常响应（status >= 400）和关键路径（如 /api/v1/pay），避免日志爆炸
字段建议固定结构：timestamp、req_id（用 uuid.NewString() 注入）、method、path、query、headers（白名单）、req_body_truncated、status、resp_size、duration_ms。
最易被忽略的是时区和精度 —— time.Now().UnixMilli() 比 time.Now().String() 更省空间且无时区歧义；而 req_id 必须透传到下游服务，否则链路断开。
