日志不丢失的关键在于lumberjack必须作为logrus.Out或zap.Core的直接Writer，且进程退出前必须显式调用Sync()或Close()；否则缓冲区日志大概率丢失。
日志不丢失的关键在于：lumberjack 必须作为 logrus.Out 或 zap.Core 的直接 Writer，且进程退出前必须显式调用 Sync() 或 Close() —— 否则缓冲区里最后几条日志大概率消失。
为什么Gin + lumberjack 会丢日志？
常见现象是服务收到 SIGTERM 后立即退出，但最后一秒的请求日志没写进文件；或 panic 恢复后部分错误堆栈缺失。根本原因不是 lumberjack 本身，而是 Go 日志库默认异步/缓冲写入，而 lumberjack 不自动 flush。
-
logrus默认使用io.Writer接口，但不保证 Write() 返回即落盘 —— 它依赖底层 Writer 自行处理缓冲 -
zap更激进：默认启用zapcore.LockWrap和缓冲队列，Write() 成功 ≠ 写入磁盘 - lumberjack 的
Write()方法只负责写入当前文件句柄，不触发fsync，也不管理上层日志库的缓冲区
logrus 场景下如何确保不丢日志
必须把 lumberjack.Logger 直接赋给 logrus.SetOutput()，并在程序退出前调用其 Close() 方法（不是 Rotate()）。
- 错误写法：
logrus.SetOutput(io.MultiWriter(os.Stdout, &lumberjack.Logger{}))—— MultiWriter 不暴露 Close，lumberjack 被包裹后无法手动关闭 - 正确写法：
l := &lumberjack.Logger{Filename: "app.log", MaxSize: 100 * 1024 * 1024, Mode: 0644}; logrus.SetOutput(l) - 退出时必须：
defer l.Close()（或在 signal handler 中显式调用），否则未 flush 的缓冲数据永久丢失 - 注意：
l.Close()会阻塞直到所有 pending write 完成并 fsync，因此要放在 graceful shutdown 流程末尾
zap 场景下必须配 Sync() 才安全
zap 的 Core 封装了 lumberjack，但不会自动代理 Close() —— 你得自己拿到底层 lumberjack 实例，或依赖 zap 提供的同步机制。
- 推荐组合：
zapcore.NewCore(encoder, zapcore.AddSync(&lumberjack.Logger{}), level) - 关键点：
zapcore.AddSync会包装 Writer 并提供Sync()方法，但该方法不等于 lumberjack 的Close() - 真正保险的做法是：启动时保存 lumberjack 实例指针，退出前先调
logger.Sync()（刷 zap 缓冲），再调lumberjack.Close()（刷文件系统缓冲） - 漏掉任一环节都可能丢最后 1~3 条日志 —— 尤其在容器环境里，SIGTERM 后只有几秒存活窗口
Windows 下静默失败导致“看似没丢、实则卡住”
当 lumberjack 尝试 rename 旧日志文件时，若文件正被资源管理器、VS Code 或其他进程打开，os.Rename 会失败，但 lumberjack 不返回 error，也不重试 —— 日志继续写进原文件，切割停滞，磁盘悄悄涨满。
- 现象：日志文件大小远超
MaxSize，但没生成.1、.2备份文件 - 验证方式：用
handle.exe（Sysinternals 工具）检查日志文件句柄持有者 - 规避手段：确保日志目录不被 GUI 工具实时预览；或改用
lumberjack.MaxBackups = 0关闭归档，仅靠大小轮转（牺牲历史保留） - 生产建议：Linux 环境更可靠；Windows 部署时务必测试
lumberjack.Close()是否能成功 rename
最易被忽略的是：lumberjack 的 Close() 不是可选操作，它和 logrus.Info() 一样属于必须显式调用的关键路径 —— 少写一行 defer，线上就可能少一条关键 panic 日志。
