gin.Logger()无法自定义字段或结构化输出，因其内部硬编码格式、不暴露结构化数据、不支持上下文透传；必须通过自定义中间件或集成zap/logrus等日志库实现JSON输出、trace_id注入及字段扩展。
直接用 gin.Logger() 输出的日志没法自定义字段、也没法结构化，想统一格式必须自己写中间件或换日志库——别指望靠 gin.DefaultWriter 重定向就能改格式。
为什么 gin.Logger() 的输出不能直接格式化
gin.Logger() 是个黑盒中间件，内部用 log.Printf 拼字符串，不暴露结构化数据。你改不了它的字段顺序、加不了 trace_id、也塞不进 JSON 字段。哪怕把 gin.DefaultWriter 指向文件或 io.MultiWriter，输出内容还是固定那几项：时间、状态码、耗时、IP、方法、路径。
- 它不走任何 logger 接口（比如
logrus或zap的Info()），所以无法 hook - 字段名硬编码（如
| 200 |），不能替换为"status":200 - 没有上下文透传能力，
c.Request.Context()里的值拿不到
用自定义中间件替代 gin.Logger()
最轻量、最可控的做法是自己实现一个等效的访问日志中间件，用你喜欢的结构化日志库输出。以 logrus 为例：
- 用
c.Next()前后测耗时，c.Writer.Status()拿状态码 - 从
c.Request提取RemoteAddr、UserAgent()、Referer() - 用
c.Errors.ByType(gin.ErrorTypePrivate)获取中间件里c.Error()推入的错误 - 所有字段都走
logrus.WithFields()，自然支持 JSON、Text、自定义格式
示例片段：
func AccessLog(logger *logrus.Logger) gin.HandlerFunc {
return func(c *gin.Context) {
start := time.Now()
c.Next()
latency := time.Since(start)
logger.WithFields(logrus.Fields{
"status": c.Writer.Status(),
"method": c.Request.Method,
"path": c.Request.URL.Path,
"query": c.Request.URL.RawQuery,
"ip": c.ClientIP(),
"user_agent": c.Request.UserAgent(),
"latency": latency.Microseconds(),
"error": c.Errors.ByType(gin.ErrorTypePrivate).String(),
}).Info("")
}
}
panic 日志必须单独捕获到 error.log
gin.Recovery() 默认把 panic 堆栈打到 gin.DefaultWriter，和访问日志混在一起。线上出问题时，你要翻半天才能定位 panic 行。正确做法是用 gin.RecoveryWithWriter() 把 panic 隔离到独立文件：
- 打开一个只写、追加模式的文件句柄：
errFile, _ := os.OpenFile("error.log", os.O_CREATE|os.O_WRONLY|os.O_APPEND, 0644) - 调用
r.Use(gin.RecoveryWithWriter(errFile))，而不是gin.Recovery() - 注意：这个文件句柄要一直持有，不能在中间件里每次打开关闭，否则会丢失日志
这样 panic 和 recover 堆栈就只出现在 error.log，和 access log 物理分离，查问题时不用 grep 过滤。
logrus/zap 选哪个？关键看归档需求
如果只是格式统一、输出到文件，logrus 足够，API 简单，JSONFormatter 开箱即用；但如果要自动切割、压缩、按天轮转，logrus 得配 lumberjack，而 zap 原生支持 WriteSyncer + lumberjack 组合，更稳：
-
logrus：适合中小项目，快速上手，但并发高时性能略逊 -
zap：适合中大型服务，尤其需要日志归档、低延迟场景，但初始化稍重 - 两者都得自己实现中间件，没“一键接入”方案——Gin 不提供日志库绑定层
真正容易被忽略的是：无论用哪个库，gin.RecoveryWithWriter 的文件句柄生命周期必须和 server 生命周期一致，关 server 前记得 errFile.Close()，否则最后一段 panic 日志可能丢失。
