如何在Golang中输出结构化日志_结构化日志实现方式

Go 1.21+ 原生 slog 需用 slog.NewJSONHandler 包装输出目标才能输出 JSON,字段名小驼峰且不可自定义,不支持嵌套结构体自动展开;zerolog 零分配高性能但需手动设时间格式、字段类型严格、全局 level 变更不生效于已有实例;zap 平衡性能与功能,支持多输出、采样、caller 追踪,推荐 zap.Logger;结构化日志关键在字段命名规范、类型一致、敏感信息脱敏及数值字段用数字类型。

log/slog 输出 JSON 格式结构化日志

Go 1.21+ 原生 slog 是最轻量、无第三

方依赖的结构化日志方案。默认输出是文本,要 JSON 必须显式配置 slog.NewJSONHandler

  • 必须把 os.Stdout(或文件)包装进 slog.NewJSONHandler,再传给 slog.New,否则仍输出纯文本
  • 字段名默认小驼峰(如 user_id),不支持自定义 key 名,若需 userId 得自己封装 handler
  • 不支持嵌套结构体自动展开,slog.Any("req", req) 会转成字符串,不是 JSON object
slog.SetDefault(slog.New(
    slog.NewJSONHandler(os.Stdout, &slog.HandlerOptions{AddSource: true}),
))
slog.Info("user login", "user_id", 123, "ip", "192.168.1.1")

输出为一行 JSON:{"time":"2025-05-20T10:30:45.123Z","level":"INFO","msg":"user login","user_id":123,"ip":"192.168.1.1","source":"main.go:12"}

zerolog 实现零分配、高性能结构化日志

zerolog 是 Go 生态最常用的结构化日志库,核心优势是避免 fmt 和反射开销,字段写入直接拼接字节流。

  • 默认输出无时间戳、无 level 字段,需手动加:zerolog.TimeFieldFormat = time.RFC3339,且必须在创建 logger 前设置
  • 字段类型严格:传 int64 就用 Int64(),传 string 就用 Str(),混用会导致 panic 或静默丢弃
  • 不支持全局 logger 的 level 动态调整(如运行时从 info 切到 debug),得靠 zerolog.SetGlobalLevel(),但已有 logger 实例不会响应变化
log := zerolog.New(os.Stdout).With().
    Timestamp().
    Str("service", "api").
    Logger()
log.Info().Int("attempts", 3).Str("user", "alice").Msg("login failed")

输出:{"level":"info","time":"2025-05-20T10:30:45Z","service":"api","attempts":3,"user":"alice","message":"login failed"}

为什么 zap 在大型服务中更常见

zap 平衡了性能、功能和易用性,适合需要多输出目标(文件 + 网络)、采样、字段过滤的场景,但 API 略重。

  • 必须区分 zap.Logger(带 encoder、writer)和 zap.SugaredLogger(语法糖,性能略低),生产环境推荐前者
  • JSON encoder 默认不输出 caller(文件行号),需显式启用:zap.AddCaller(),否则排查问题时缺上下文
  • 日志级别由 logger 实例决定,不是全局状态,可为不同模块创建不同 level 的 logger,比如 dbLog.Debug()httpLog.Info()
logger, _ := zap.NewProduction(zap.AddCaller(), zap.AddStacktrace(zap.WarnLevel))
defer logger.Sync()
logger.Info("request handled", zap.String("path", "/health"), zap.Int("status", 200))

结构化日志字段设计容易被忽略的细节

字段命名和类型一致性比选哪个库更重要。Kubernetes、Loki、Datadog 等后端都依赖固定字段做聚合与查询。

  • 不要用动态 key,比如 "error_code_"+code,应统一为 "error_code" 字段 + 不同值
  • 敏感字段如 passwordtoken 必须在写入前过滤,slogzerolog 都不提供自动脱敏
  • HTTP 请求 ID 推荐用 request_id(全小写+下划线),而非 requestId,避免不同服务字段名不一致导致日志平台无法关联
  • 数值类字段(耗时、数量)统一用数字类型,别转成字符串,否则 Grafana 里无法做 avg / p95 计算

字段一旦上线就很难改,上线前最好和 SRE 或可观测平台负责人对齐命名规范。