直接用 log 包在微服务中会出问题，因其缺乏结构化字段（如 trace_id）、无统一日志出口、本地文件易满盘/并发写错乱、stdout 依赖外部采集且易丢失；需改用 zap/zerolog 实现结构化、异步远端输出，并通过 context 统一透传 trace_id。
为什么直接用 log 包在微服务里会出问题
微服务部署后，日志分散在多台机器、多个进程里，log 包默认输出到标准输出或文件，既没结构化字段（如 trace_id、service_name），也没统一出口，查问题时得挨个登录服务器 grep，根本没法关联一次请求的完整链路。
更实际的问题是：日志写文件时若不控制轮转和压缩，磁盘几天就爆；多 goroutine 并发写同一个文件还可能丢日志或错乱；而直接 stdout 输出又依赖容器平台日志采集器（比如 Docker 的 json-file driver），一旦采集失败就彻底丢失。
- 必须给每条日志打上
trace_id、span_id、service_name、level等字段，方便后续检索与链路追踪对齐 - 日志输出目标不能只依赖本地文件，要支持写入 Kafka / gRPC / HTTP endpoint 等远端收集器
- 本地缓冲和异步写入是刚需，避免日志逻辑阻塞业务 goroutine
用 zap + zerolog 做结构化日志输出
zap 是目前 Go 生态最主流的高性能结构化日志库，启动快、内存分配少、支持字段动态注入；zerolog 更轻量，API 更简洁，适合对二进制体积敏感的场景。二者都原生支持 JSON 输出，可直接被 Logstash、Loki 或 OpenTelemetry Collector 消费。
关键不是“选哪个”，而是别混用——一个服务统一用一种，否则日志格式不一致，后端解析规则就得写两套。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 用
zap.NewProduction()启动时自动带time、level、caller字段，但需手动加trace_id：在中间件里从 context 取出trace_id，通过logger.With(zap.String("trace_id", tid))生成子 logger - 避免在 hot path 上拼接字符串传给
logger.Info()，改用字段方式：logger.Info("db query slow", zap.String("sql", sql), zap.Duration("duration", d)) - 不要用
fmt.Sprintf构造 message 字段，这会丢失结构化能力；message 字段只放固定提示语，所有变量走字段参数
如何把日志发到远端而不拖慢业务
同步调用 HTTP 或 Kafka 发日志等于把业务逻辑绑死在日志链路上，网络抖动或下游不可用会导致整个服务响应变慢甚至超时。必须做异步解耦 + 本地缓冲 + 失败重试 + 降级策略。
常见做法是用 goroutine + channel 做日志队列，但要注意 channel 容量和背压：无缓冲 channel 容易阻塞，过大 buffer 又吃内存。更稳妥的是用带限流的异步 writer，比如 lumberjack 配合 zapcore.WriteSyncer 封装 Kafka producer，或直接集成 opentelemetry-go/exporters/otlp/otlptrace 的日志 exporter。
- 设置日志 channel 缓冲大小为 1024～4096，配合
select+default保证非阻塞写入；满时丢弃低优先级日志（如debug）而非卡住业务 - Kafka 写入失败时，先 fallback 到本地
lumberjack.Logger文件，等恢复后再补传（需自己实现 checkpoint 和 offset 记录） - 若使用 OpenTelemetry Collector，日志走 OTLP 协议发往
http://otel-collector:4318/v1/logs，注意配置retry_on_failure和queue参数
分布式环境下 trace_id 怎么透传和注入
Go 里没有 Java 那种 ThreadLocal，context.Context 是唯一可靠的透传载体。但很多人只在 HTTP 入口解析 trace_id，忘了 gRPC、消息队列、定时任务这些入口也要补全。
典型漏点：HTTP handler 解析了 X-Trace-ID 并写入 context，但调用下游 gRPC 时没把该字段塞进 metadata.MD；或者消费 Kafka 消息时，没从消息 header 提取 trace_id 并新建 context。
- HTTP 中间件用
r.Header.Get("X-Trace-ID")或opentelemetry-go-contrib/instrumentation/net/http/otelhttp自动注入 - gRPC client 拦截器里用
grpc.Header把trace_id写入 metadata；server 拦截器从metadata.FromIncomingContext取出并注入 context - Kafka consumer 要检查
msg.Headers，用otel.GetTextMapPropagator().Extract()解析 trace 上下文，再传给业务 handler
最容易被忽略的是日志初始化时机——必须在第一个 context 创建后、任何日志调用前，就基于该 context 构建带 trace_id 的 logger 实例，否则所有日志都会缺字段。
