go服务应将日志输出到stdout/stderr而非文件，因容器运行时仅捕获标准流以对接日志驱动；写文件会绕过采集链路、引发竞态、脱离生命周期管理且不被K8s日志后端支持。
Go 服务在容器中默认将日志输出到 stdout 和 stderr，这是最佳实践；直接写文件或轮转日志反而会破坏容器日志采集链路。
为什么不能在 Go 程序里自己轮转日志文件
容器运行时（如 docker、containerd）只捕获进程的 stdout/stderr 流，并转发给日志驱动（json-file、syslog、fluentd 等）。一旦 Go 程序用 os.OpenFile 写本地文件：
- 该文件不在容器日志路径下，
docker logs完全看不到 - 多个副本共享挂载卷时，多进程写同一文件易导致内容错乱或丢失
- 日志生命周期脱离容器管理，无法自动清理、压缩、归档
- K8s 的
ClusterLogging或 Loki 等后端通常只对接标准流，不拉取容器内任意路径的文件
用 log 包 + os.Stdout 输出结构化日志
Go 标准 log 包本身不支持 json，但可轻松封装成结构化输出。关键不是“用什么库”，而是“输出到哪里”和“格式是否可解析”：
import ( "encoding/json" "log" "os" "time" ) type LogEntry struct { Time time.Time `json:"time"` Level String `json:"level"` Msg string `json:"msg"` Data map[string]interface{} `json:"data,omitempty"` } func main() { // 直接写到 stdout，不加缓冲、不重定向 log.SetOutput(os.Stdout) log.SetFlags(0) // 关闭默认时间戳等，由我们自己控制 entry := LogEntry{ Time: time.Now(), Level: "info", Msg: "service started", Data: map[string]interface{}{"port": 8080}, } enc := json.NewEncoder(os.Stdout) enc.Encode(entry) // 输出一行 JSON，方便 fluentd / vector 解析 }- 每条日志必须是单行 JSON（换行分隔），否则日志采集器会解析失败
- 避免在
enc.Encode()前/后额外打印空行或前缀（比如log.Println混用） - 不要调用
log.SetPrefix或log.SetFlags，它们会污染 JSON 格式
使用 zerolog 或 zap 时的容器适配要点
第三方日志库更高效，但需显式配置输出目标与格式：
立即学习“go语言免费学习笔记（深入）”；
-
zerolog.New(os.Stdout).With().timestamp().Logger()—— 默认就是 JSON +stdout，开箱即用 -
zap.NewProductionConfig().OutputPaths = []string{"stdout"}—— 必须显式设为"stdout"，不能留空或写[""] - 禁用
zap.NewDevelopmentConfig()：它带颜色、多行、含 caller，不适合机器解析 - 若用
lumberjack做轮转，立刻删掉——它写文件，和容器日志模型冲突
容器部署时必须检查的三项配置
即使 Go 程序输出正确，K8s 或 Docker 配置错误仍会导致日志丢失：
- Docker 运行时：避免
--log-driver=none；生产环境推荐--log-driver=fluentd或vector - K8s Pod spec：
containers[].env中不要设置LOG_LEVEL=debug类似变量来控制 Go 日志开关——应由程序启动参数或配置中心控制，而非靠环境变量触发写文件行为 - 确保容器进程 PID 为 1（即 Go 二进制直接作为 entrypoint），否则
stdout可能被 shell 层截断或缓冲；用exec "$@"启动脚本时要加exec
最常被忽略的是缓冲问题：Go 默认对 os.Stdout 使用行缓冲（遇到 n 刷出），但若日志没换行、或 panic 前未 flush，可能丢失最后几条。上线前务必用 log.SetOutput(os.Stderr) 做对比测试，确认 stderr 同样可靠——因为部分日志驱动对 stderr 更敏感。