zap本身不支持自动日志切割，因其设计仅负责高性能序列化日志并写入writesyncer，不管理文件生命周期；日志切割必须由lumberjack等第三方writesyncer实现，且需正确配置filename（绝对路径）、maxsize（mb）、maxage与maxbackups共存、localtime:true等参数。
Zap 本身不支持自动日志切割，无论你用 zap.NewProduction() 还是 zap.NewDevelopment()，日志都会持续追加到单个文件（或 stdout），不会按大小、时间或日期切分——这不是配置问题，而是设计使然。
为什么 zap.NewProduction() 配置再全也切不了日志
Zap 的核心职责是高性能序列化日志 Entry 并写入 WriteSyncer，它不管理文件生命周期。所谓“自动切割”，实际由底层 WriteSyncer 实现，而 zap.NewProduction() 内部用的是 os.Stderr，根本不走文件 IO，更谈不上轮转。
- 直接调用该函数后改
EncoderConfig或加LevelEnabler，对切割毫无影响 - 常见误操作：以为设置
MaxSize或MaxAge是 zap 的参数，其实它们属于lumberjack.Logger字段，必须显式构造并传入 - 开发环境若用
os.Stdout测试切割逻辑，永远看不到文件生成——得先换为文件型WriteSyncer
用 lumberjack.Logger 接入 Zap 的关键配置项
lumberjack 是目前最稳定、被 Zap 官方文档隐式推荐的轮转写入器，但字段语义和生效条件容易踩坑：
-
Filename必须是绝对路径（如"/var/log/myapp/app.log"），相对路径在 daemon 模式下常写到/或权限拒绝目录 -
MaxSize单位是 MB（不是字节），值设为100比1024更稳妥：太大导致单文件臃肿，太小引发高频 IO 切割 -
MaxAge: 7和MaxBackups: 30建议共存：前者按“文件最后修改时间”清理过期文件，后者防突发日志暴涨撑爆磁盘 - 务必设
LocalTime: true，否则文件名和清理判断用 UTC 时间，在中国服务器上会导致归档错乱（比如凌晨写入的日志被算作前一天）
按天切割必须自己封装 RotateWriter
lumberjack 的 MaxAge 是“存活天数”，不是“自然日切割”。它只在写日志时检查文件是否超龄，不会在每天 00:00 主动新建文件。要实现真正的按天切（如 app-2026-07-14.log），必须自定义 WriteSyncer：
- 每次
Write()前比对time.Now().Format("2006-01-02")和当前文件日期，不一致则关闭旧文件、打开新文件 - 用
sync.RWMutex保护current io.Writer和date string状态，避免并发写入时状态错乱 - 新文件路径建议含日期，如
fmt.Sprintf("log/app-%s.log", today)；Close()中必须显式关掉旧文件句柄，否则 Linux 下易触发too many open files - 不要在
Write()热路径里做os.OpenFile()，应延迟到checkAndRotate()这类非高频调用中
真正难的不是写几行轮转代码，而是理解 Zap 的边界：它只管“怎么写”，不管“写到哪”和“什么时候换地方”。所有切割逻辑都发生在 WriteSyncer 层，一旦混淆这个分工，配置再细致也白搭。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
