gorm默认日志无法直接接入elk，因其config.logger仅接受gormlogger.interface实现，输出无结构纯文本，缺乏时间戳、level及可提取字段；需自定义zapgormlogger实现trace方法，显式拆解sql、rows、duration等为独立zap.field，并注入trace_id、service.name等统一字段，禁用zap.any避免json嵌套与敏感信息泄露。
为什么 GORM 默认日志不能直接进 ELK
GORM 的 Config.Logger 接口只接受实现了 gormlogger.Interface 的对象，它输出的是纯文本（如 SELECT * FROM users WHERE id = ?），字段无结构、无时间戳、无 level 标识。Logstash 或 Filebeat 无法自动提取 sql、rows、duration 等关键字段，更别说关联 trace_id 或 service.name。
用 GormLogger 封装 zap.Logger 实现结构化 SQL 日志
必须自己实现 gormlogger.Interface，把每条 SQL 操作转成带固定字段的 zap 日志条目。核心是重写 Trace 方法：
- 不要用
zap.String("msg", ...)拼接整条 SQL —— 这会让 SQL 变成单个字符串字段，无法被 Elasticsearch 做 term 查询 - 必须拆解：用
zap.String("sql", sql)、zap.Int64("rows", rows)、zap.Duration("duration", dur)、zap.String("level", "info")等显式字段 - 从
ctx中提取trace_id（比如从req.Context()或中间件注入的值），再通过logger.With(zap.String("trace_id", tid))构建子 logger - 错误日志必须用
zap.Error(err)，不是zap.String("error", err.Error())—— 后者丢失堆栈和类型信息
示例关键片段：
type ZapGormLogger struct {
logger *zap.Logger
}
<p>func (l *ZapGormLogger) Trace(ctx context.Context, begin time.Time, fc func() (string, int64), err error) {
dur := time.Since(begin)
sql, rows := fc()
fields := []zap.Field{
zap.String("sql", sql),
zap.Int64("rows", rows),
zap.Duration("duration", dur),
zap.String("level", "info"),
}
if err != nil {
fields = append(fields, zap.Error(err))
}
if tid, ok := ctx.Value("trace_id").(string); ok {
fields = append(fields, zap.String("trace_id", tid))
}
l.logger.Info("db query", fields...)
}
</p>
避免在 GORM 日志中滥用 zap.Any 或反射
GORM 有时会传入 map[string]interface{} 或 struct 作为参数（比如 Create(&user) 中的 user）。这时候容易想“用 zap.Any("params", args) 一键打进去”——但这是错的：
-
zap.Any("params", user)会把整个 struct 序列化成一个 JSON 字符串字段，字段名还是params，不是user_name、email等独立可检索字段 - ELK 里查
user_name: "alice"会失败，只能全文匹配或靠 pipeline 解析，性能差且不可靠 - 真正需要记录参数时，应手动展开：
zap.String("user_name", user.Name)、zap.String("email", user.Email)，字段名必须是 string literal - 敏感字段（如 password、token）必须显式过滤，
zap.Any不会自动脱敏
与 HTTP 请求日志对齐 trace_id 和 service.name
GORM 日志要能和上游 HTTP 日志串联，必须保证 trace_id 和 service.name 字段名、格式完全一致：
-
service.name必须是字符串字面量，不能是变量；推荐统一设为"user-service"这类静态值 -
trace_id字段名必须和 Jaeger/SkyWalking SDK 输出的一致（通常是trace_id，不是traceId或X-Trace-ID） - 别在 GORM logger 里重复设
service.name—— 应该在全局zap.Logger初始化时就用logger.With(zap.String("service.name", "user-service"))注入，所有子 logger 自动继承 - 如果用了
lumberjack写文件，确保OutputPaths包含日志文件路径，且目录存在、有写权限，否则 SQL 日志会静默丢弃
最易被忽略的一点：GORM 的 Trace 方法可能被并发调用，zap.Logger 本身是并发安全的，但如果你在 Trace 里临时改了 encoder config 或调用了 Sync()，就会引发竞态。保持 logger 实例只读、只调用 Info/Error 等方法即可。
