lumberjack.Logger 是 Gin 日志切割的默认选择，因其直接实现 io.Writer 接口、线程安全、支持按大小（MB）/天数自动轮转、备份保留与 gzip 压缩，且切割逻辑在 Write 时原子执行；常见错误是手动 os.OpenFile 导致并发冲突与日志丢失。
为什么 lumberjack.Logger 是 Gin 日志切割的默认选择
因为 Gin 原生 gin.DefaultWriter 只接受一个 io.Writer，而 lumberjack.Logger 正好实现了该接口，且自带线程安全、按大小/天数轮转、备份保留和 gzip 压缩能力。logrus 或 zap 本身都不提供轮转逻辑——它们只负责格式化和写入，切割必须由底层 Writer 完成。
常见错误是直接用 os.OpenFile 每次写前判断大小再 reopen：这会导致并发写冲突、SIGTERM 时日志丢失、rename 冲突，且无法保证原子性。而 lumberjack.Logger 在每次 Write 后自动检查 MaxSize 和 MaxAge，触发时完成 close → rename → new file 三步，全程加锁保护。
-
MaxSize单位是 MB（不是字节），默认 100；设为 10 表示每 10MB 切一次，太小会频繁 rename，影响高吞吐场景 -
MaxBackups控制保留几个历史文件，设为0表示不限制，但磁盘可能被撑爆 -
MaxAge是“最后修改时间”距今的天数，和日志内容里的时间戳无关；它不会在每天 0 点强制切，只在写入时检查是否超期 - 目录必须提前创建（
os.MkdirAll），否则首次写入失败且无报错
如何让 Gin 的访问日志同时输出到终端和切割文件
不能直接把 lumberjack.Logger 赋给 gin.DefaultWriter，否则控制台就看不到实时日志了。正确做法是用 io.MultiWriter 组合多个 writer：
lj := &lumberjack.Logger{
Filename: "logs/access.log",
MaxSize: 50, // MB
MaxBackups: 7,
MaxAge: 30, // 天
Compress: true,
}
gin.DefaultWriter = io.MultiWriter(lj, os.Stdout)
注意：这个赋值必须在 gin.New() 或 gin.Default() 之后、任何路由注册之前执行，否则中间件已绑定旧 writer，后续更改无效。
立即学习“go语言免费学习笔记（深入）”；
- 如果用了自定义 Logger 中间件（比如基于
zap的GinLogger），就不要动DefaultWriter，而是把lumberjack.Logger作为zap的WriteSyncer传进去 -
lumberjack.Logger实例必须全局复用，不能每次请求都 new 一个，否则每个实例独立计数，切割失效 - 若需区分访问日志和错误日志，应分别初始化两个
lumberjack.Logger实例，对应不同Filename和参数
zap + lumberjack 配合 Gin 时的三个关键初始化点
zap 本身不处理文件切割，所以必须把 lumberjack.Logger 包装成 zapcore.WriteSyncer 才能接入。最容易出错的是时机和生命周期管理：
- 先初始化
lumberjack.Logger，再用它构造zapcore.AddSync得到WriteSyncer，最后传给zapcore.NewCore - 整个应用生命周期内，
lumberjack.Logger实例只能有一个，且应在main()开头就创建，避免被 GC 提前回收 - 程序退出前必须调用
logger.Sync()（zap）和lj.Close()（lumberjack），否则缓冲区或 pending rename 可能丢失最后一段日志 - 若用
zap.NewProduction()，它内部已封装了同步逻辑，但仍建议在defer中显式调用logger.Sync()
按日期命名文件？lumberjack 不支持，得换方案
lumberjack.Logger 的文件名固定为 Filename + .N（如 access.log.1），不支持 access-2026-08-12.log 这类按日期命名的模式。如果你明确需要“每天一个独立文件”，它就不适用。
此时有两个务实选择：
- 用原生
io.Writer实现：自己实现Write方法，每次写前检查当前日期是否变化，变化则Close()旧文件、OpenFile新文件。但要注意并发安全和 panic 恢复 - 改用
file-rotatelogs（lestrrat-go/file-rotatelogs），它支持按时间间隔（如24h）轮转，并可配置文件名模板，但依赖系统时钟，对 NTP 调整敏感 - 最稳妥的做法仍是接受
lumberjack的命名规则，配合外部工具（如 logrotate）做二次归档，生产环境更可控
真正容易被忽略的是：所有日志 Writer 都必须在进程退出前显式 Close 或 Sync，否则最后几 KB 日志大概率丢失——这点在容器环境下尤其明显，SIGTERM 发出后留给 Go 程序的优雅退出窗口往往不足 1 秒。
