因为gin.defaultwriter只是io.writer接口实现，不带轮转逻辑，无法检查日期变化、文件大小或自动重命名；zap需配合lumberjack，通过maxage、localtime等配置实现按天切割。
为什么默认的 gin.DefaultWriter 无法按天分割日志
因为 gin.DefaultWriter 只是一个 io.Writer 接口实现，底层直接写到 os.Stdout 或文件句柄，不带任何轮转逻辑。它不会检查日期变化、文件大小或自动重命名，更不会保留历史备份——你看到的“日志文件越来越大”，本质是单个文件持续追加。
Zap 配合 lumberjack 实现按天切割的关键配置项
Zap 本身不提供日志轮转能力，必须靠第三方日志写入器（如 lumberjack）补足。关键不是“用 Zap”，而是怎么把它和轮转逻辑桥接起来：
-
lumberjack.MaxAge控制保留多少天的旧日志（单位：天），设为7表示只留最近一周 -
lumberjack.LocalTime必须设为true，否则按 UTC 时间切分，国内服务器容易错一天 -
lumberjack.Filename要指定完整路径（如"log/app.log"），且目录需提前存在并有写权限 -
Zap的WriteSyncer必须包装成lumberjack.Logger，不能直接传文件句柄
示例片段：
logger := zap.New(zapcore.NewCore(
encoder,
zapcore.AddSync(&lumberjack.Logger{
Filename: "log/app.log",
MaxSize: 100, // MB
MaxBackups: 30,
MaxAge: 7,
LocalTime: true,
}),
zapcore.InfoLevel,
))
Gin 的 gin.LoggerWithConfig 怎么对接自定义 Zap 日志器
Gin 自带的 gin.Logger() 固定绑定 gin.DefaultWriter，没法插拔。必须用 gin.LoggerWithConfig 并手动把 Zap 的 Sugar 或 Logger 包装进 gin.LoggerConfig.Output：
-
Output字段必须是io.Writer，所以得用zapcore.AddSync(zapLogger.Desugar().Sync)或更稳妥地——自己封装一个io.Writer实现，把每条 Gin 日志格式化后交给Zap记录 - 别直接用
zapLogger.Sync()，它返回的是error，不是io.Writer - 常见错误：把
zapLogger.Sugar()直接塞进Output，会 panic，因为Sugar不是io.Writer
推荐做法是写一个轻量适配器：
type zapWriter struct{ logger *zap.Logger }
func (w *zapWriter) Write(p []byte) (n int, err error) {
w.logger.Info(strings.TrimSpace(string(p)))
return len(p), nil
}
r.Use(gin.LoggerWithConfig(gin.LoggerConfig{
Output: &zapWriter{logger: zapLogger},
}))
备份文件名里为什么看不到日期，只有序号
lumberjack 默认按“大小+序号”轮转（如 app.log.1、app.log.2），不按日期命名。它靠 MaxAge 删除过期文件，但不生成 app-2026-08-10.log 这类文件——这是设计使然，不是配置遗漏。
如果硬要按日期命名，得放弃 lumberjack，改用 file-rotatelogs 或自行实现 io.WriteCloser，但会增加维护成本；多数生产环境接受序号命名 + MaxAge 组合，既稳定又便于脚本清理。
真正容易被忽略的是：lumberjack 的 LocalTime 默认为 false，不显式设 true 就可能在凌晨触发错误切割点——尤其当服务部署在 Docker 容器且未同步宿主机时区时，这个问题会静默发生。
