Golang微服务日志需统一结构化输出到stdou
t，用zap+lumberjack规范格式、注入traceID、字段对齐，并由Fluent Bit等采集器转发至Loki/ES。
用 Golang 做微服务时，日志不能各写各的文件、各打各的格式——得统一采集、结构化输出、集中分析。核心就三点：规范日志格式（JSON）、打到标准输出（stdout）、配合日志采集器（如 Filebeat / Fluent Bit）转发到 ES 或 Loki。
统一用结构化日志库（推荐 zap + lumberjack）
别用 fmt.Println 或 log.Printf，它们非结构化、无字段、难过滤。zap 是 Go 生态最主流的高性能结构化日志库，搭配 lumberjack 可轮转日志文件（但微服务更推荐直接输出到 stdout）。
- 初始化 zap logger，设置 JSON 编码、添加服务名、实例 ID、traceID 等上下文字段
- HTTP 中间件里自动注入 traceID（比如从请求头 X-Request-ID 获取或生成），并透传到所有子日志
- 关键业务逻辑用 SugaredLogger 或 Logger 打日志，字段命名保持一致（如 "user_id", "order_id", "status_code"）
日志必须输出到 stdout，不写本地文件（除非调试）
Kubernetes 或 Docker 环境下，容器日志默认捕获 stdout/stderr。写本地文件反而难收集，还可能占满磁盘。
- 禁用 zap 的文件写入（不配 WriteSyncer 到文件）
- 确保启动时没重定向 os.Stdout —— 容器运行时靠它抓日志
- 若需本地调试，可用环境变量控制是否同时写文件（上线关闭）
配合采集器做轻量转发（Filebeat 或 Fluent Bit）
Go 服务不自己连 ES 或 Kafka。交给专用采集器：它监听容器 stdout，加一层 enrich（如加 host、namespace、pod_name），再发往后端。
- 在 K8s 中用 DaemonSet 部署 Fluent Bit，配置 tail 输入插件读取 /var/log/containers/*.log
- 用 parser 过滤出你的服务日志（通过 container_name 或 label 匹配）
- 输出到 Loki（轻量级日志聚合）或 Elasticsearch + Kibana（适合复杂查询和告警）
日志内容要带可观测性关键字段
光有 message 不够。每条日志至少包含：时间戳、level、service、trace_id、span_id、http_method、path、status_code、latency_ms、error（如有）。这样查问题才快。
- HTTP handler 中记录请求开始和结束，用 defer 计算耗时，用 ctx.Value 提取 traceID
- 数据库调用、RPC 调用也打结构化日志，字段对齐（如 "db_query", "rpc_to_user_svc"）
- 错误日志必须带 error stack（zap.Error(err) 自动展开），不要只写 err.Error()
基本上就这些。不复杂但容易忽略——重点不是“怎么记”，而是“记成什么样”和“谁来收”。Golang 微服务的日志价值，不在量大，而在结构一致、上下文完整、链路可溯。
t，用zap+lumberjack规范格式、注入traceID、字段对齐，并由Fluent Bit等采集器转发至Loki/ES。