gorm 默认日志不能直接对接 zap，因 zap.logger 未实现 gormlogger.interface 接口；需用适配器将 gorm 日志参数转为 zap.field，显式映射 sql、rows、duration 等字段，并通过 context 注入 trace_id 等请求级信息，同时避免高频创建 logger 实例和反射开销。
为什么 GORM 默认日志不能直接对接 Zap
GORM 的 Config.Logger 接口只接受实现了 gormlogger.Interface 的对象，而 *zap.Logger 并不满足该接口——它没有 Trace、Info 等方法，也不能接收 context.Context 和 gormlogger.Config 参数。硬塞进去会编译失败或 panic。
常见错误是直接写 logger: zap.NewProduction() 赋值给 Config.Logger，结果 GORM 启动就报错：cannot use *zap.Logger as gormlogger.Interface。
- 必须用
zap.NewLogger()或zap.New()构建的实例，再包装一层适配器 - 不能用
zap.SugaredLogger，它缺少结构化字段的类型安全保证，GORM 日志字段（如sql、rows、duration）会丢失类型信息 - 别在每次 SQL 执行时 new 一个 logger 实例——GORM 可能每秒执行数百次查询，反复初始化 encoder 和 core 会拖慢吞吐
如何实现 GORM + Zap 的结构化日志适配器
核心是实现 gormlogger.Interface，把 GORM 的日志参数转成 zap.Field 列表，再交给底层 *zap.Logger 输出。关键字段必须显式映射：
-
sql→zap.String("sql", sql)（注意：需调用strings.TrimSpace去掉换行和空格） -
rows→zap.Int64("rows", result.RowsAffected) -
duration→zap.Duration("duration", elapsed)（不是字符串格式化） -
error→zap.Error(err)（不是zap.Any("err", err)，否则堆栈不展开） -
scope.InstanceID→zap.String("instance_id", scope.InstanceID)（用于关联请求上下文）
示例适配器片段：
type ZapGormLogger struct {
logger *zap.Logger
}
func (l *ZapGormLogger) Trace(ctx context.Context, begin time.Time, fc func() (string, int64), err error) {
elapsed := time.Since(begin)
sql, rows := fc()
fields := []zap.Field{
zap.String("event", "gorm_trace"),
zap.String("sql", strings.TrimSpace(sql)),
zap.Int64("rows", rows),
zap.Duration("duration", elapsed),
}
if err != nil {
fields = append(fields, zap.Error(err))
}
l.logger.Info("SQL executed", fields...)
}
怎样把 trace_id、user_id 等请求级字段注入 GORM 日志
GORM 不自动继承 HTTP 请求的 context，所以 context.WithValue(ctx, key, value) 存的字段不会被日志适配器自动读取。必须手动桥接：
- 在 handler 中，用
db.WithContext(ctx)把 context 传入 GORM 操作 - 在适配器的
Trace方法里，从ctx提取字段：traceID := ctx.Value(traceKey).(string)，然后加进fields列表 - 别在适配器里调
logger.With()创建新实例——高频 SQL 下开销明显；应提前在 handler 里衍生带基础字段的 logger，再传给适配器 - 如果用了 OpenTelemetry，推荐从
trace.SpanFromContext(ctx).SpanContext().TraceID().String()提取，而非依赖 header
字段名要和你的日志平台对齐（比如 Loki 要求 traceID，Elasticsearch 可能习惯 trace_id），统一命名避免后续查日志翻车。
性能陷阱：采样、锁、编码方式怎么配
GORM 日志高频且重复（比如批量 insert、join 查询），配置不当会让日志本身成为瓶颈：
-
zap.NewProduction()默认开启 sampling，GORM 的Trace调用可能被静默丢弃——必须显式禁用：cfg := zap.NewProductionConfig(); cfg.Sampling = nil - 写文件时，
lumberjack.Logger必须用zapcore.Lock(zapcore.AddSync(...))包裹，否则多 goroutine 写同一文件句柄会 panic - 编码必须用
JSON，且EncodeTime设为zapcore.ISO8601TimeEncoder；自定义时间格式（如time.Now().Format("2006-01-02 15:04:05")）会触发 GC 分配，压测中延迟毛刺明显 - 别在适配器里用
zap.Reflect打整个scope——反射慢，且 GORM 内部 struct 字段不可控，容易 panic
最易被忽略的是：GORM 的 Trace 方法在事务提交/回滚、预处理语句准备等环节也会被调用，这些非主 SQL 路径的日志字段常被漏掉 trace_id 或 service 名，导致链路断点。
