Echo框架使用Zap和Lumberjack实现日志切割落盘-Golang-PHP中文网

zap本身不支持自动日志切割，因其设计仅负责高性能序列化日志并写入writesyncer，不管理文件生命周期；日志切割必须由lumberjack等第三方writesyncer实现，且需正确配置filename（绝对路径）、maxsize（mb）、maxage与maxbackups共存、localtime:true等参数。

echo框架使用zap和lumberjack实现日志切割落盘

为什么直接用 `zap.NewProduction()` 无法切割日志

因为 zap.NewProduction() 默认使用 os.Stderr 作为输出目标，它是个不可重定向的文件描述符，不支持按大小或时间轮转。Lumberjack 的 Write 方法必须被显式调用，而 Zap 的 Core 不会自动把写入委托给 Lumberjack —— 你得自己造一个能对接两者的 WriteSyncer。

常见错误现象：
• 日志一直追加到单个大文件，磁盘爆满
• 配置了 Lumberjack.Logger 却没生效，Write 根本没被调用
• 启动时报错 cannot assign *lumberjack.Logger to zapcore.WriteSyncer

必须手动包装 *lumberjack.Logger 实现 zapcore.WriteSyncer 接口（重点是 Write 和 Sync）
Sync() 必须调用底层 Lumberjack.Sync()，否则日志可能丢失
别用 zapcore.AddSync() 直接传 *lumberjack.Logger —— 它只做类型断言，不自动适配

如何构造可切割的 `zap.Logger` 实例

核心是把 *lumberjack.Logger 转成 zapcore.WriteSyncer，再塞进 zapcore.NewCore。不需要改 Echo 的中间件逻辑，只需在初始化 logger 时替换掉默认的 core。

典型配置示例：

lj := &lumberjack.Logger{
    Filename:   "logs/app.log",
    MaxSize:    100, // MB
    MaxBackups: 7,
    MaxAge:     28, // days
    Compress:   true,
}
writeSyncer := zapcore.AddSync(lj)
encoder := zap.NewProductionEncoderConfig()
encoder.TimeKey = "time"
encoder.EncodeTime = zapcore.ISO8601TimeEncoder

core := zapcore.NewCore(
    zapcore.NewJSONEncoder(encoder),
    writeSyncer,
    zapcore.InfoLevel,
)

logger := zap.New(core).Named("echo")

MaxSize 单位是 MB，不是字节；设太小会导致频繁切片和锁竞争
如果用 zap.NewDevelopmentEncoderConfig()，注意它默认不带 EncodeTime，时间字段会为空
务必调用 .Named("echo") 或类似命名，否则所有日志都打在 root logger 下，不好隔离

怎么让 Echo 框架真正用上这个 logger

Echo 的 e.Logger 是个 *echolog.Logger，和 Zap 完全无关。不能直接赋值，必须通过 echo.HTTPErrorHandler、echo.HTTPErrorHandler 和中间件手动注入，或者更干脆：绕过它，自己管理日志输出点。

Echo框架 5.1.0

Echo框架 5.1.0 版本源码包下载，适合关注 RealIP 行为变化、StartConfig.Listener、NewDefaultFS 和观测性中间件入口的开发团队。

下载

推荐做法是写一个中间件，在请求入口/出口统一打结构化日志，并完全忽略 e.Logger：

func ZapLogger(logger *zap.Logger) echo.MiddlewareFunc {
    return func(next echo.HandlerFunc) echo.HandlerFunc {
        return func(c echo.Context) error {
            start := time.Now()
            if err := next(c); err != nil {
                logger.Error("request failed",
                    zap.String("path", c.Request().URL.Path),
                    zap.Int("status", c.Response().Status),
                    zap.Duration("latency", time.Since(start)),
                    zap.Error(err),
                )
                return err
            }
            logger.Info("request completed",
                zap.String("path", c.Request().URL.Path),
                zap.Int("status", c.Response().Status),
                zap.Duration("latency", time.Since(start)),
            )
            return nil
        }
    }
}

不要试图重写 e.Logger.Output() —— 它只是个 io.Writer，没法透出结构化字段
错误处理里别漏掉 c.Response().Status，它在 next(c) 后才确定，放错位置会记录成 0
如果用了 echo.HTTPErrorHandler，也要用同样方式调用 logger.Error，否则 404/500 等错误不会落盘

常见切割失败原因和验证方法

最常被忽略的是权限和路径问题：Lumberjack 在首次写入前不会创建目录，mkdir -p logs 必须手动执行；另外 Windows 下路径分隔符写错（如用 "logs\app.log"）也会静默失败。

验证是否真正在切割：

启动服务后立刻检查 logs/ 目录是否存在、是否有 app.log 文件生成
用 curl 发几次请求，然后 ls -la logs/ 看文件大小是否增长
手动 touch logs/app.log && chmod 000 logs/app.log，观察日志是否报 permission denied 错误
把 MaxSize 改成 1（MB），发足够请求触发切割，看是否生成 app-2024-01-01_00-00-00.log.gz 类似文件