直接用lumberjack.Logger替换Gin默认日志写入器可实现切割，但需正确配置参数并确保初始化时机：Filename须为绝对路径、提前创建父目录、避免多goroutine并发调用SetOutput，否则会导致丢日志、不轮转或panic。
直接用 lumberjack.Logger 替换 Gin 默认日志写入器就能实现切割，但不配好参数或没处理好初始化时机，日志会丢、文件不轮转、甚至 panic。
为什么 Gin 默认日志不能直接切分
Gin 的 gin.DefaultWriter 是一个 io.Writer 接口实例，默认指向 os.Stdout。它本身不支持按大小/时间自动切割——这得靠 lumberjack.Logger 这类封装了轮转逻辑的 writer 来承担。你不能把 lumberjack.Logger 直接塞给 gin.SetMode() 或类似调用，必须显式替换日志输出目标。
常见错误现象包括：
- 日志写到文件后不再生成新备份，
MaxBackups形同虚设 - 服务启动时提示
open /var/log/myapp/error.log: permission denied - 多实例并发写同一日志文件，内容错乱或丢失（尤其在容器中未做 volume 挂载时）
如何安全替换 Gin 的默认日志输出器
关键在于两处：一是用 gin.SetOutput() 统一接管所有标准日志（如 gin.Logger() 中间件），二是确保 lumberjack.Logger 实例在首次写入前已初始化完毕且路径可写。
实操建议：
- 创建
lumberjack.Logger实例时，Filename必须是绝对路径，避免工作目录变动导致写入失败 - 在
main()开头就调用os.MkdirAll(filepath.Dir(filename), 0755)确保父目录存在 - 不要在多个 goroutine 中重复调用
gin.SetOutput()，它不是线程安全的 - 若同时需要控制台+文件双写，用
io.MultiWriter(os.Stdout, &lumberjack.Logger{...})，但注意os.Stdout在容器中可能被重定向，颜色字符要关掉：gin.DisableConsoleColor()
RecoveryWithWriter 配合 lumberjack 写错误日志的坑
gin.RecoveryWithWriter() 专用于捕获 panic 并写入错误日志，但它只接管 panic 场景，不处理 HTTP 4xx/5xx 响应。很多人误以为设了它就“全量错误日志都有了”，其实不然。
容易踩的坑：
-
RecoveryWithWriter的第二个参数是自定义 error handler 函数，不是 logger 实例——别传错类型 - 如果
lumberjack.Logger的MaxSize设得太小（比如 1MB），而 panic 频繁触发堆栈很长，可能单次写入就超限，导致轮转失败 - 没调用
logger.Sync()（对lumberjack无效，但对 zap 等组合场景很重要），panic 后进程退出，缓冲区日志丢失 - 错误日志和访问日志用了两个不同的
lumberjack.Logger实例，但共用同一Filename，结果文件被覆盖或损坏
zap + lumberjack 组合时的初始化顺序问题
如果你用 zap 而非 Gin 原生日志中间件，lumberjack.Logger 就只是 zap.New(...) 的一个 WriteSyncer 输入，此时初始化顺序更敏感。
必须保证：
-
lumberjack.Logger实例先于zap.New(...)创建，否则zap构造时拿不到有效 writer - 使用
zapcore.AddSync()包裹&lumberjack.Logger{...}，而不是裸指针 - 若用
zap.NewProduction()，它内部默认启用json.Encoder，和lumberjack兼容；但若自己拼EncoderConfig，记得设TimeKey和LevelKey字段名，否则日志解析困难 -
lumberjack的Compress: true会启用 gzip，但某些日志采集器（如 filebeat 旧版本）不支持直接读取 .gz 文件，需确认下游兼容性
最易被忽略的一点：lumberjack 不做任何日志内容过滤或格式控制，它只管“怎么写、写到哪、何时切”。真正决定日志是否该记录、记录什么字段、是否结构化的，是上层日志库（logrus/zap）和你的中间件逻辑——别指望靠改 MaxAge 来减少日志量，该加 level filter 就加，该删 debug 字段就删。
