logrus + lumberjack 轮转失效主因是未正确设置 logrus.out：必须用 logrus.setoutput(&lumberjack.logger{...})，而非包装 writer；maxsize 单位为字节，windows 下 os.rename 被占用会静默失败；需全局单实例、禁用手动 rotate；新文件权限需显式设 mode=0644。
logrus + lumberjack 轮转配置为什么没生效？
常见现象是日志写入后文件不切割、大小超限不归档、maxSize设成 100MB 却在 2GB 才切——根本原因是 lumberjack.Logger 没被正确注入到 logrus.Logger.Out，而是只改了 Writer 或用了中间包装层。
- 必须直接赋值：
logrus.SetOutput(&lumberjack.Logger{...})，不能用logrus.SetFormatter或自定义io.Writer包装器绕过 -
maxSize单位是字节，不是 MB；写100 * 1024 * 1024，别写100或"100MB" - Windows 下注意：
lumberjack依赖os.Rename原子重命名，若目标文件正被其他进程打开（如文本编辑器），轮转会静默失败，无错误提示
如何避免并发写入时文件切割错乱？
多个 goroutine 同时调用 logrus.Info 时，lumberjack 内部的切割判断和文件切换不是完全原子的——尤其在高吞吐场景下，可能产生重复内容或切割点偏移。
- 确保全局只用一个
*logrus.Logger实例，不要在每个 handler 里 new 一个 - 不要手动调用
lumberjack.Rotate()，它不线程安全；切割必须交给Write()内部触发 - 如果业务中存在批量日志（如循环内密集打点），建议加一层缓冲或合并日志条目，减少
Write()调用频次
rotate 后旧文件权限变成 0600 怎么办？
lumberjack 默认用 os.OpenFile 创建新文件，权限硬编码为 0600，旧文件重命名后继承原权限，但新文件总是私有——运维查日志时经常卡在这儿。
- 必须显式设置
lumberjack.Logger.Mode，例如：Mode: 0644 - 注意：该字段只影响新创建的日志文件，已存在的旧文件权限不会自动修正，需配合外部脚本或启动时
os.Chmod - Linux 下若进程以非 root 运行，
0644可能仍无法被其他用户读取，需确认 umask 是否覆盖了权限位
替代方案：要不要自己实现轮转逻辑？
用 lumberjack 确实省事，但它不支持按小时切割、压缩归档、保留策略（如“只留最近 7 天”）等进阶需求。自己实现看似复杂，其实核心就三件事：检查大小/时间、rename、open 新文件。
立即学习“go语言免费学习笔记（深入）”；
- 关键点在于：所有文件操作必须包裹在
sync.Mutex里，且Write()中的判断和Rotate()必须在同一锁下完成 - 避免用
time.Now().Hour()做小时切割，要监听time.Ticker触发定时 rotate，否则跨小时瞬间可能漏切 - 压缩可延后处理：切割完成后起 goroutine 异步调用
gzip命令，别阻塞主写入流
真正难的不是轮转本身，而是边界情况——比如磁盘满时 rotate 失败、SIGTERM 期间正在写入、符号链接指向的日志路径变更。这些地方一旦忽略，线上就只能靠重启恢复。
