统一日志格式需用zap/zerolog输出JSON，注入service、request_id、trace_id等通用字段，通过中间件自动绑定上下文，错误日志须结构化记录err和堆栈。
在 Go 微服务中实现统一日志格式，核心是用结构化日志库替代 log 包的原始字符串输出，优先选用 JSON 格式便于采集、过滤与分析。关键不在于“写得漂亮”，而在于字段一致、上下文可追溯、错误可定位。
选对日志库：zap 或 zerolog 是主流选择
Zap（Uber）和 zerolog（rs）都默认输出 JSON，性能高、无反射、支持字段动态注入，比 logrus 更轻量且更符合云原生日志规范。zap 的 SugaredLogger 适合开发调试， Logger （结构化模式）更适合生产环境。
- 避免用
fmt.Sprintf拼接日志消息——丢失结构、难提取字段 - 不要手动构建 JSON 字符串——易出错、无法复用上下文、不支持日志级别动态控制
- zap 默认时间字段是纳秒级整数，建议用
zap.Time("ts", time.Now())自动转为 ISO8601 字符串
定义通用日志字段：服务名、请求 ID、追踪 ID 不可少
微服务日志必须能关联一次完整调用链。除时间、级别、消息外，至少包含：
-
service：当前服务名称（如
"auth-service"），建议从环境变量读取 -
request_id：每个 HTTP 请求/GRPC 调用生成唯一 ID（可用
uuid.New().String()） - trace_id：若集成 OpenTelemetry，应透传并记录 trace_id 和 span_id
-
caller：开启 zap 的
WithCaller(true)，方便快速定位源码位置
这些字段应通过 logger.With(...) 在中间件或入口处一次性注入，后续所有日志自动携带，无需重复传参。
立即学习“go语言免费学习笔记（深入）”；
HTTP 中间件自动注入请求上下文
以 Gin 或标准 net/http 为例，在日志中间件中提取或生成 request_id，并绑定到 logger 实例：
- 检查 Header 中是否已有
X-Request-ID，有则复用；否则生成新 ID - 用
ctx = context.WithValue(ctx, loggerKey, logger.With(zap.String("request_id", reqID)))传递 - Handler 内通过
logger := ctx.Value(loggerKey).(*zap.Logger)获取带上下文的 logger - 错误日志务必用
logger.Error("db query failed", zap.Error(err), zap.String("sql", stmt))，而非logger.Error(err.Error())
标准化错误日志与堆栈处理
Go 的 error 本身不带堆栈，需借助 github.com/pkg/errors 或 golang.org/x/xerrors（Go 1.13+）包装，并在日志中显式记录：
- 使用
zap.NamedError("err", err)可序列化 error 类型和消息 - 需要堆栈时，用
zap.String("stack", debug.Stack())（仅调试环境）或封装 helper 函数自动提取 - 区分业务错误（如 “user not found”）和系统错误（如 “redis timeout”），前者用 Info 级别+明确 code 字段，后者用 Error 级别+完整上下文
基本上就这些。JSON 日志不是加个 json.Marshal 就算结构化，关键是字段语义清晰、上下文自动继承、错误可诊断。zap 配合中间件 + 统一字段约定，三步就能落地，不复杂但容易忽略细节。
