Go标准库log包不支持自动归档，因其仅写入io.Writer且不感知文件生命周期；需用lumberjack等第三方库实现线程安全、原子性的轮转、压缩与清理。
为什么 log 包原生不支持自动归档
Go 标准库的 log 包设计极简，只负责写入 io.Writer，不感知文件生命周期。它不会检查文件大小、不轮转、不压缩、不清理旧日志——这些全得自己补。直接用 os.OpenFile 配合 log.SetOutput 写死一个文件，跑几天就撑爆磁盘。
常见错误是用定时器每分钟检查一次文件大小再手动 rename —— 这在高并发写入下极易因竞态导致丢失日志或覆盖归档文件。
- 归档必须原子：重命名 + 创建新文件需在单次 syscall 级完成（如
os.Rename+os.Create不能拆开） - 写入不能阻塞：归档触发时，新日志仍要继续写入新文件，不能等压缩或删除完成
- 时间戳精度要够：同一秒内多次归档需靠序号防冲突，不能只靠
time.Now().Format("2006-01-02")
用 lumberjack.Logger 替代手写归档逻辑
lumberjack 是事实标准，轻量、无依赖、线程安全，且归档行为全部封装在 Write 方法内部。它不是装饰器，而是实现了 io.WriteCloser，可直接传给 log.SetOutput。
关键参数必须显式设，否则默认值极不适用生产：
立即学习“go语言免费学习笔记（深入）”；
-
Filename: 必须是绝对路径，相对路径在 daemon 场景下会指向启动目录而非预期位置 -
MaxSize: 单位是 MB，不是字节；设为100表示 100MB，不是100 * 1024 * 1024 -
MaxBackups: 归档文件保留数，设为0表示不限——但磁盘空间失控风险得自己兜底 -
LocalTime: 设为true，否则归档文件名用 UTC 时间，排查时易混淆
示例：
lw := &lumberjack.Logger{
Filename: "/var/log/myapp/app.log",
MaxSize: 50, // MB
MaxBackups: 7,
MaxAge: 28, // 天
Compress: true,
LocalTime: true,
}
log.SetOutput(lw)归档触发时机与写入性能影响
归档只在每次 Write 调用中检查，不是后台 goroutine 定时扫描。这意味着：如果日志写入稀疏（比如每分钟只几条），归档可能延迟数分钟；但只要写入频繁，归档响应就是实时的。
性能上，lumberjack 在归档瞬间会有微小停顿（rename + open 新文件），但整个过程在毫秒级，且不影响其他 goroutine 的写入——因为它用 sync.Mutex 锁的是自身实例，不是全局日志锁。
- 避免在
MaxSize设得过小（如 1MB）：频繁归档会增加系统调用和磁盘 I/O 压力 - 不要开启
Compress: true同时又设MaxBackups过大：gzip 压缩是同步阻塞的，备份数多时归档耗时明显上升 - 若应用对延迟极度敏感（如高频交易），可考虑关闭
Compress，用外部工具（logrotate）做异步压缩
如何安全替换正在使用的日志文件句柄
某些场景需运行时切换日志路径（如按租户隔离），此时不能简单 new 一个 lumberjack.Logger 并 SetOutput——老句柄未 close，文件描述符泄漏，且旧日志可能还在写。
正确做法是：先调用旧 logger 的 Close()，再 SetOutput 新实例。注意 lumberjack.Logger.Close() 会阻塞直到当前写入完成，并关闭底层文件句柄。
- 务必检查
Close()返回 error，常见原因是文件已被外部进程删除或权限变更 - 切换后立即写一条测试日志，验证新路径是否可写（尤其容器环境，挂载目录可能只读）
- 不要在 HTTP handler 或 RPC 方法里频繁 Close+Reopen：这会放大锁竞争，应由配置热更新模块统一协调
归档的边界其实很窄：它只管“文件怎么切”，不管“日志怎么结构化”或“怎么推送到 ELK”。想加 JSON 格式或 traceID 注入，得在 log 上层封装，而不是动归档逻辑本身。
