Go标准库log不支持自动轮转，因SetOutput设为os.File后仅持续写入原文件描述符，无法感知路径变化；需用lumberjack等封装或手动实现原子切换。
为什么 log.SetOutput 直接接 os.File 无法自动轮转
Go 标准库的 log 包本身不支持日志轮转。一旦你用 log.SetOutput 把输出设为一个打开的 *os.File，它就只是持续写入——哪怕文件被外部命令重命名或删除，Go 进程仍会往原文件描述符里写，不会感知路径变化。常见错误是以为改个文件名、用 log.SetOutput 重新赋值就能“切换”，但旧句柄没关闭，新文件没做并发保护，结果日志错乱或丢失。
真正可行的做法是：自己控制文件生命周期，或用成熟封装。核心约束有三个：不能丢日志、不能阻塞主流程、轮转时要原子切换输出目标。
用 lumberjack.Logger 实现安全轮转（推荐）
lumberjack 是目前最稳定、被 gin / grpc-go 等广泛采用的日志轮转封装。它把轮转逻辑全收在 Write 方法里，和标准 log 或 io.Writer 接口无缝对接，不用改日志调用方式。
- 需显式设置
MaxSize（单位 MB）、MaxBackups、MaxAge（天），否则默认不清理旧文件 - 轮转触发时机是每次
Write前检查，不是定时器驱动，所以低频服务可能长期不轮转 - 多个进程不能共用同一个
lumberjack.Logger实例（会竞争），但可共用同一日志路径（它内部用flock防冲突） - 注意
LocalTime: true，否则归档文件名里的时间是 UTC，排查时容易看错
import (
"log"
"os"
"gopkg.in/natefinch/lumberjack.v2"
)
func setupLogger() {
logger := &lumberjack.Logger{
Filename: "/var/log/myapp/app.log",
MaxSize: 100, // MB
MaxBackups: 7,
MaxAge: 28, // days
LocalTime: true,
Compress: true,
}
log.SetOutput(logger)
}
手动轮转时如何避免日志丢失与竞态
如果因合规要求必须自研（比如要集成审计签名、写入对象存储），关键在于轮转瞬间的原子性。直接 os.Rename + os.Create 不够——写入可能发生在 rename 后、create 前的空窗期。
立即学习“go语言免费学习笔记（深入）”；
- 始终用
os.OpenFile(filename, os.O_CREATE|os.O_WRONLY|os.O_APPEND, 0644)打开新文件，不要用os.Create（会 truncate） - 轮转前先
file.Close()当前句柄，再os.Rename旧文件，最后打开新文件并log.SetOutput - 整个过程必须加互斥锁（
sync.Mutex），且锁范围覆盖 close → rename → open → setOutput 全流程 - 若日志量大，建议把轮转逻辑放在独立 goroutine，但
SetOutput调用仍需锁保护，因为log内部无锁
容器环境下的特殊处理：stdout 不该轮转，但要适配日志驱动
Kubernetes 或 Docker 默认把 stdout / stderr 交给容器运行时统一采集（如 docker logs 或 fluentd）。此时你在 Go 里对 os.Stdout 做轮转毫无意义，反而干扰日志收集链路。
- 容器内应优先输出到
os.Stdout，让平台负责归档；只在需要结构化日志（如 JSON）、或必须落盘审计时才写文件 - 若必须写文件，路径应挂载为
emptyDir或 hostPath，并确保lumberjack的Filename指向该路径 - Docker 的
json-file日志驱动支持max-size和max-file参数，可在daemon.json中全局配置，比应用层轮转更轻量
轮转真正的难点不在代码，而在边界：进程崩溃时未 flush 的缓冲、SIGTERM 信号到来时的关闭顺序、多实例共享存储的锁粒度。这些地方没压测过，上线后第一周大概率出问题。
