gin.logger()不能直接推送日志中心，因其仅向gin.defaultwriter写入纯文本、无结构化、不支持异步、无hook机制、无法注入trace_id等上下文字段，且不提供原始日志结构，难以对接kafka/loki/es等系统。
为什么 gin.Logger() 不能直接推送到日志中心
因为 gin.Logger() 只写入 gin.DefaultWriter（默认是 os.Stdout），它不暴露原始日志结构、不支持异步、不提供 hook 接口，也没法注入 trace_id 或 user_id 等上下文字段。你把它重定向到文件或 io.MultiWriter，本质上还是在“搬运字符串”，没法对接 Kafka、Loki、ES 或 OpenTelemetry Collector。
用 zap + 自定义中间件替代 gin.Logger()
生产环境真正可行的路径是：弃用 gin.Logger()，自己写一个返回 gin.HandlerFunc 的中间件，内部用 zap.Logger 输出结构化日志，并通过 c.Get("trace_id")、c.ClientIP()、c.Request.Header.Get("User-Agent") 等补全字段。
关键点：
- 必须在中间件里调用
c.Next()，否则拿不到响应状态码和耗时 - 用
defer+recover()捕获 panic 是可选的，但访问日志中间件一般不负责这个（交给gin.Recovery()更清晰） - 别在中间件里直接调
logger.Info()—— 要判断c.Writer.Status()是否为 0（说明还没写响应，可能 panic 了），否则日志会漏掉失败请求 - 示例片段：
func ZapAccessLog(logger *zap.Logger) gin.HandlerFunc {
return func(c *gin.Context) {
start := time.Now()
c.Next()
// 避免记录未完成的响应（如 panic 导致 Writer.Status() == 0）
status := c.Writer.Status()
if status == 0 {
status = 500
}
logger.Info("http_access",
zap.String("method", c.Request.Method),
zap.String("path", c.Request.URL.Path),
zap.Int("status", status),
zap.Duration("latency", time.Since(start)),
zap.String("client_ip", c.ClientIP()),
zap.String("user_agent", c.Request.UserAgent()),
zap.String("trace_id", c.GetString("trace_id")), // 前置中间件注入
)
}
}
如何把日志发到 Loki / Kafka / ES
zap 本身不带网络输出能力，得靠封装 zapcore.Core 或用现成驱动：
- 推 Loki：用
grafana/loki/clients/pkg/promtail/client写自定义zapcore.WriteSyncer，注意 batch 和 retry - 推 Kafka：用
segmentio/kafka-go包做异步 producer，不要阻塞 HTTP 请求；建议加内存 buffer（如chan []byte）防背压 - 推 ES：用
olivere/elastic/v7或直接 POST JSON 到 bulk API；避免每条日志都建连接，要复用*elastic.Client - 所有网络写入必须设超时（比如 3s），失败时 fallback 到本地文件（
os.OpenFile(..., os.O_APPEND|os.O_CREATE)）
容易被忽略的上下文传递问题
很多团队卡在 trace_id 传不下去——不是中间件没写，而是没在链路起点注入。常见错误：
- 只在某个路由组里用了 trace 中间件，但
gin.Logger()或 Recovery 还在全局注册，导致日志和 trace 断开 - 用
c.Set("trace_id", ...)后，没在后续中间件里显式调用c.Get("trace_id")，zap 日志里就是空字符串 - HTTP header 名大小写不一致：
c.Request.Header.Get("X-Trace-ID")vs 实际发送的是x-trace-id（Go 的http.Header是 case-insensitive，但别依赖这个） - 并发请求共享 logger 实例没问题，但别在中间件里 new zap.Logger —— 它是线程安全的，且初始化开销大
最稳的做法：从第一个中间件开始解析 header，c.Set() 一次，后面所有中间件（包括日志）统一 c.GetString()，不重复解析。
