Go应用必须用结构化日志库（如zap/zerolog）输出JSON格式日志，配合Loki label策略、采样控制与时间精度对齐，否则日志不可查、不可聚合、无法告警。
Go 本身没有内置的日志收集服务，云原生场景下必须依赖外部组件协同工作；直接用 log 包写文件或标准输出，在 Kubernetes 中会丢失上下文、无法按 Pod/Container 聚合、也不支持结构化与采样——这不是“能不能用”的问题，而是“用了就等于没日志”的问题。
为什么不能直接用 log.Printf 输出到 stdout/stderr？
Kubernetes 默认将容器的 stdout 和 stderr 重定向到 /var/log/pods/... 下的 JSON 文件，但原始日志若非 JSON 格式，会被 Fluent Bit / Filebeat 当作单行文本处理，丢失字段（如 trace_id、level、request_id）；更关键的是，Go 默认 log 不带时间戳精度（默认秒级）、无调用位置、无法动态切换输出目标。
- 必须用结构化日志库（如
zap、zerolog），且显式启用 JSON 编码 - 避免在日志中拼接字符串（
log.Printf("user %s failed", u.Name)），改用字段方式：logger.Error().Str("user", u.Name).Msg("login failed") - 如果使用
zap，务必调用zap.AddCaller()和zap.TimeEncoder(zap.RFC3339NanoTimeEncoder)，否则 Kibana 或 Loki 查询时无法准确定位和排序
如何让 Go 应用适配 Loki + Promtail 架构？
Loki 不索引日志内容，只索引 label，所以 Go 日志的 label 必须稳定、低基数、有业务意义。Promtail 通过静态标签（job、host）和 pipeline stages（如 regex、labels）提取动态 label，但 Go 进程自身无法控制 Promtail 配置——只能靠日志格式配合。
- 在每条日志中固定写入
{"app":"auth-service","env":"prod","version":"v1.2.3"}这类 label 字段（用zerolog.With().Str("app", "auth-service").Logger()初始化） - 避免把 HTTP path、user_id 这类高基数字段打到顶级 label，应放在日志 message 内部或用 Loki 的
__line__正则提取（例如用stage.regex: {expression: "user_id=(?P）\\w+)"} → stage.labels: {user_id: ""} - 如果用
zerolog，开启zerolog.TimeFieldFormat = zerolog.TimeFormatUnixMs，和 Loki 的时间解析对齐，防止因毫秒/纳秒差异导致日志乱序
怎样避免日志采集导致 Go 应用 OOM 或延迟飙升？
结构化日志库（尤其 zap）虽快，但若日志量突增（如循环内打 debug 日志），仍可能阻塞 goroutine 或压垮内存。云原生环境里，日志写入不是“尽力而为”，而是“必须可控”。
立即学习“go语言免费学习笔记（深入）”；
- 用
zap.L().Check(zap.DebugLevel, "slow query").Write(...)替代无条件Debug()，提前判断是否启用了该等级 - 对高频路径（如 HTTP middleware）加采样：
zap.WrapCore(func(core zapcore.Core) zapcore.Core { return zapcore.NewSampler(core, time.Second, 10, 100) })（每秒最多 10 条，100 条里留 10 条） - 禁止在 defer 里打日志（如
defer logger.Info().Msg("exit")），因为 defer 堆积会拖慢函数返回，且 panic 场景下可能重复记录 - 如果用
zerolog，设置zerolog.SetGlobalLevel(zerolog.WarnLevel)并通过环境变量动态调整，而非硬编码InfoLevel
真正难的不是把日志打出来，而是让每条日志在 Loki 里可查、在 Grafana 里可聚合、在告警规则里可匹配——这要求从 Go 的 logger 初始化那一刻起，就和集群的 label 策略、采样配置、保留周期对齐。漏掉任意一环，查日志时就会发现：能看见，但找不到；能 grep，但没法 sum by。
