Logrus 与 lumberjack 必须配对使用，前者仅负责格式化输出，后者提供轮转能力；需同时配置 logrus.Out 和 gin.DefaultWriter，并启用 JSON 格式与路径过滤以实现生产级日志管理。
logrus 与 lumberjack 轮转日志必须配对使用
单纯用 os.OpenFile 写死一个文件名，根本做不到轮转；lumberjack.Logger 才是真正负责切割、归档、压缩的底层实现。Logrus 本身不带轮转能力，它只管格式化和输出，轮转逻辑全靠 lumberjack 提供的 io.Writer 接口实现。
常见错误是：只装了 github.com/sirupsen/logrus，却没引入 github.com/natefinch/lumberjack，然后试图调用 Rotate() 或设置 MaxAge —— 这些字段根本不存在于原生 *os.File 上，会直接编译失败或静默忽略。
- 必须用
lumberjack.Logger实例替代*os.File作为 Logrus 的Out -
lumberjackv2 和 v3 API 不兼容，推荐用 v2（gopkg.in/natefinch/lumberjack.v2），v3 已停止维护 - 路径权限问题常被忽略：若
Filename指向/var/log/myapp/，应用需有该目录的写权限，否则启动时lumberjack不报错但日志写入失败
lumberjack 初始化参数直接影响磁盘占用和运维成本
lumberjack.Logger 的四个关键参数不是随便填的数字，它们共同决定日志生命周期和 IO 压力：
-
MaxSize：单个日志文件最大大小（单位 MB），设太小会导致频繁切割、inode 消耗快；设太大则单文件难排查，建议 10–100MB -
MaxBackups：保留历史备份份数，设为 0 表示不限制，生产环境务必限制（如 7），否则磁盘迟早被撑爆 -
MaxAge：日志文件最长保留天数，和MaxBackups是“与”关系——文件既超龄又超备份数才被删 -
Compress：启用 gzip 压缩能省 60%+ 空间，但首次读取需解压，调试时可关，上线建议开
例如：MaxSize=50 + MaxBackups=14 + MaxAge=30，意味着最多存 14 个 50MB 文件，且其中任意一个超过 30 天就删——实际占用空间可控，也满足审计留存要求。
立即学习“go语言免费学习笔记（深入）”；
gin.DefaultWriter 和 logrus.Out 必须分开配置
很多人误以为只要把 lumberjack.Logger 赋给 logrus.Out，Gin 的默认日志就会自动轮转。事实并非如此：Gin 的 Logger() 中间件默认只写入 gin.DefaultWriter，而它和 logrus.Out 是两个独立出口。
正确做法是两处都要设：
- 给
logrus.Logger实例设.Out = &lumberjack.Logger{...}，用于你手动调用log.Info()等地方 - 同时设
gin.DefaultWriter = io.MultiWriter(&lumberjack.Logger{...}, os.Stdout)，让 Gin 自带的请求日志也走轮转 - 若只设其一，会出现「手动打的日志进轮转文件，Gin 自动打的请求日志还在控制台或旧文件里」这种割裂现象
注意：io.MultiWriter 会把同一份日志同时写入多个目标，别重复打开同一个 lumberjack 实例两次，否则日志会翻倍写入。
JSON 格式 + SkipPaths 是生产环境刚需
纯文本日志在 ELK、Loki 或 Grafana 中几乎无法高效过滤和聚合，logrus.JSONFormatter{} 是结构化前提。但仅格式化还不够，高频无意义路径（如 /healthz、/metrics）会快速刷爆磁盘。
必须显式过滤：
- 用
gin.LoggerWithConfig替代默认gin.Logger()，传入skipPaths切片 - 跳过路径要写完整匹配路径，不是前缀匹配：比如
skipPaths = []string{"/healthz", "/readyz"}，而不是"/health" - 跳过逻辑发生在日志写入前，不产生任何 IO，性能零损耗
漏掉这步，哪怕轮转参数再合理，一天内也可能生成上百个日志文件——因为健康检查每秒几十次，每次都被记成一条完整 JSON 日志。
轮转不是加个包就能跑起来的事，核心在于 lumberjack 的参数语义、gin 和 logrus 两个日志出口的同步、以及结构化与过滤的强制落地。少任何一个环节，都只是看上去能轮转，实际上埋着磁盘告警或排查黑洞。
