不能用log.printf直接输出到文件或控制台，因其输出无结构纯文本，缺失trace_id、service_name等关键字段及精确时间戳和日志级别，elk/loki无法解析过滤；k8s仅采集stdout/stderr，写本地文件的日志不被采集器捕获；多goroutine并发写同一文件会导致内容错乱或丢失。
为什么不能用 log.Printf 直接输出到文件或控制台
因为微服务部署在多个 Pod 或节点上，log.Printf 输出的是无结构纯文本，既没有 trace_id、service_name 字段，也不带时间精度和日志级别标识。ELK/Loki 这类系统无法提取字段做过滤或聚合；Kubernetes 的 docker json-file 日志驱动只接管 os.Stdout/os.Stderr，写本地文件的日志根本不会被采集器看到；更严重的是多 goroutine 并发写同一文件会导致内容错乱或丢失。
zap.NewProduction() 必须配合哪些配置才真正可用
默认的 zap.NewProduction() 看似开箱即用，但直接用于集群环境会踩三个坑：输出路径没指定（默认写 os.Stderr，但 K8s 采集器可能只监听 stdout）、没注入关键字段、没做同步保障。实操建议：
- 显式设置
cfg.OutputPaths = []string{"stdout"}，避免误写文件路径 - 用
logger.With(zap.String("service_name", os.Getenv("SERVICE_NAME")))初始化根 logger，别等打点时再加 - 必须在
main()退出前调用logger.Sync()，否则 Pod 重启时未 flush 的日志永久丢失 - 禁用颜色和缩进：
cfg.EncoderConfig.EncodeLevel = zapcore.CapitalLevelEncoder
如何让每条日志自动带上 trace_id 而不漏掉 goroutine
常见错误是只在 HTTP handler 入口提取一次 X-Request-ID，然后用全局变量存，结果下游 goroutine 里取不到。正确做法是绑定 context，且每次派生新 goroutine 都要传入带 context 的 logger：
- 中间件中从
r.Header.Get("X-Request-ID")取值，为空则生成新ulid.Make().String() - 用
ctx := r.Context(); logger := logger.With(zap.String("trace_id", tid)).WithOptions(zap.AddCallerSkip(1))创建子 logger - 启动 goroutine 时，显式传入该
logger，而不是用外部包级 logger - gRPC 场景下，在
UnaryServerInterceptor中同样提取并注入metadata.MD向下游透传
Kubernetes 里 Promtail 收不到日志的几个硬性检查点
Promtail 不是“配了就能收”，它依赖底层容器运行时和挂载路径是否对齐。最容易被忽略的三件事：
- 确认 Docker/K8s 使用
json-file日志驱动：docker info | grep "Logging Driver"输出必须是json-file - 检查
/var/log/pods/下是否存在对应 Pod 的 symlink，Promtail 默认只扫这个目录，不是你代码里写的/app/logs - Promtail 配置中
relabel_configs必须把__meta_kubernetes_pod_container_name映射为job，否则 Loki 里查不到 service 标签 - 如果日志里有
trace_id字段，Loki 查询时得用{job="user-svc"} | json | trace_id=`abc123`，不能直接| trace_id=`abc123`
trace_id 从 ingress controller 开始，要经过 nginx、istio、gRPC、HTTP client、异步 job，每断一环，链路就碎一次。字段命名统一、header 名一致、context 传递不丢，比选什么日志库重要得多。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
