Go 结构化日志实践：slog、request_id 与错误上下文怎么设计

Go 微服务出问题时，最怕日志只有一段自然语言，缺少 request_id、trace_id、接口名、错误类型和版本号。这样的日志无法稳定检索，也很难和指标、链路追踪对齐。

解决方案思路

用 slog 统一结构化字段，在入口中间件写入 request_id 和 trace_id，在业务层保留 error wrapping，并把错误类型、接口、版本、耗时作为固定字段。日志字段要少而稳定，避免把大对象、用户隐私和高基数字段直接写入。

核心代码示例

logger := slog.With("request_id", rid, "trace_id", tid)
logger.Info("order query", "route", "/orders/:id")
if err != nil {
    logger.Error("order query failed", "err", err, "error_type", "db_timeout")
}

运行逻辑

请求进入中间件后生成 request_id，并随 context 传到 service、repository 和下游调用。发生错误时先包装上下文，再由统一出口写日志，最后通过日志平台按 request_id 或 trace_id 找到完整请求链路。

重点观察指标

• request_id、trace_id、route、error_type 字段覆盖率
• ERROR 日志数量和业务错误码分布
• 日志采集延迟、丢弃量和查询命中率

常见误区

• 每个包各自定义字段名，导致查询无法复用
• 把完整请求体、响应体或隐私数据写入日志
• 只记录 err.Error，不保留错误类型和业务上下文

参考方案

• Go log/slog 官方文档
• errors 官方文档

落地检查

• 字段、指标和 Span 名称要稳定，便于长期聚合。
• 上线前先在灰度环境验证采集成本和数据量。
• 告警必须能指向 owner、排查入口和回滚方案。