Gin日志记录方法及中间件使用教程

Gin日志远不止调用一句gin.Logger()那么简单——它默认不记录请求体和响应体，无法满足调试、审计或问题排查的深层需求；真正可靠的日志体系需手动安全读取Body、包装ResponseWriter、结构化记录操作行为（如用户、资源、结果）、异步落库防阻塞，并严格把控中间件执行顺序（鉴权前置、Recovery后置、CORS靠前）；同时，生产环境必须增强默认Recovery中间件，实现错误脱敏、文件轮转、统一响应与实时告警。日志的价值不在“有”，而在“准、全、可追溯”——任一环节疏漏，都会让故障现场变成黑盒。

gin.Logger() 为什么日志里看不到请求体和响应体

因为 gin.Logger() 是 Gin 默认提供的轻量日志中间件，它只读取并打印请求行（method、path）、状态码、耗时、客户端 IP 等元信息，**不消费也不缓存 c.Request.Body，也不拦截 ResponseWriter**。所以你自然看不到 POST 的 JSON 内容或返回的响应数据。

• 想记录请求体？必须手动读取 c.Request.Body，再用 ioutil.NopCloser 把字节重装回去——但注意：大文件会吃内存，生产环境慎用
• 想记录响应体？必须包装 ResponseWriter（比如自定义 responseWriter 结构体），在 c.Next() 后从缓冲区取内容
• 调试阶段可用 gin.Mode() == gin.DebugMode 控制是否开启体内容记录，避免线上日志爆炸
• 别在日志中间件里调用 c.ShouldBindJSON()——它会提前读空 Body，后续 handler 绑定失败，报错变成 invalid character

自定义日志中间件怎么安全地记录操作行为（如增删改）

管理后台的「操作日志」不能简单套用 gin.Logger()，它需要结构化字段（操作人、IP、资源 ID、结果）、异步落库、且要过滤掉 GET 查询类请求。

• 用 c.Request.Method 过滤：只处理 POST、PUT、DELETE，跳过 GET
• 用户身份必须由前序鉴权中间件通过 c.Set("user", user) 显式写入；下游日志中间件要用 user, ok := c.Get("user") 判断，ok == false 就不该记日志
• 数据库写入必须放 c.Next() 之后，且建议起 goroutine 异步执行——但注意：c.Copy() 才能安全传入新协程，直接传原始 *gin.Context 会 panic
• 客户端 IP 别直接信 c.ClientIP()，要结合反向代理头（如 X-Real-IP）和可信 IP 段配置，否则内网穿透场景下全是 127.0.0.1

多个中间件顺序错了会出什么问题

中间件执行是链式调用，注册顺序 = 请求进入顺序，返回顺序则倒过来。顺序错一个，整个逻辑就可能崩。

• 鉴权中间件（如 JWT 解析）必须放在日志中间件之前：否则未登录请求也会被记日志，还可能因 c.Get("user") 返回 nil 导致 panic
• 日志中间件必须放在 Recovery 之后：否则 panic 发生时日志根本没刷出来，终端只剩一行 500，查无可查
• CORS 中间件建议放最前：不然浏览器预检 OPTIONS 请求会被鉴权拦住，报 Method Not Allowed
• 全局 r.Use(a, b, c) 和分组 group.Use(x, y) 是独立链条，后者不会继承前者——想让 API 分组带鉴权但管理后台不带，就得用分组而非全局

要不要自己写 Recovery 中间件？还是直接用 gin.Recovery()

gin.Recovery() 足够应对绝大多数 panic 场景，但默认只打屏、不落盘、不告警。生产环境几乎一定得换。

• 默认 gin.Recovery() 会把 panic 错误堆栈打到终端，但服务重启后就没了；换成 lumberjack.Logger 可按大小/天数轮转写文件
• 错误响应格式要统一：用自定义 RecoveryFunc（如 response.ServerError）返回标准 JSON，而不是裸 HTML 或空白页
• 敏感信息要脱敏：非 debug 模式下，err.Error() 不能直接返回给前端，尤其不能暴露路径、变量名、数据库语句
• 别忘了在 Recovery 里加监控上报：比如触发 Prometheus counter + 钉钉告警，否则错误静默发生，你根本不知道

今天关于《Gin日志记录方法及中间件使用教程》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！