Golang实现高效的日志切割与压缩插件-Golang-PHP中文网

logrotate不适合嵌入式go服务，因其依赖系统权限、信号机制和文件系统协作，在无root、容器化或进程独占文件场景下易失败；go进程内切割可精确控制时机、避免丢日志，lumberjack压缩需异步执行以防阻塞主线程。

golang实现高效的日志切割与压缩插件

为什么 `logrotate` 不适合嵌入式 Go 服务？

Go 进程内直接管理日志切割，比依赖外部 logrotate 更可靠——尤其在容器环境或无 root 权限时，logrotate 可能无法及时重载、信号丢失，或因文件被进程独占而报 error: failed to rename ... Permission denied。Go 自己做切割，能精确控制打开/关闭时机，避免日志丢失。

关键点在于：必须用 os.O_CREATE | os.O_APPEND | os.O_WRONLY 打开文件，且每次写前不重复 os.OpenFile；切割时用 os.Rename 原子重命名，再新建文件句柄，不能直接 Close + Reopen —— 否则在高并发写入下极易丢日志。

用 `lumberjack` 时如何避免压缩卡住主线程？

lumberjack 默认只切分不压缩，压缩得自己加逻辑。但若在 Rotate 回调里直接调用 gzip.Gzip，会阻塞日志写入 goroutine，尤其大文件（>100MB）压缩可能耗时数秒，导致 log.Print 阻塞、HTTP 请求超时。

把压缩挪到独立 goroutine：go func() { compressFile(oldFilename) }()
加简单限流：用带缓冲 channel 控制并发压缩数，比如 compressCh := make(chan struct{}, 2)，进函数先 compressCh ，完后 <code>
压缩失败不 panic，只打一条 log.Printf("failed to compress %s: %v", oldFilename, err)，否则整个日志系统挂掉

`zap` + `lumberjack` 组合的正确初始化姿势

很多人直接把 lumberjack.Logger 当 io.Writer 传给 zapcore.AddSync，结果发现切割后新日志仍写进旧文件——因为 lumberjack.Logger 的 Write 方法内部没做切割判断，它只在 Write 返回 io.ErrShortWrite 时才触发 Rotate，而实际文件大小判断在 Write 之前就该做。

正确做法是用 lumberjack.Logger 作为底层 writer，并启用它的 Rotate 和 MaxSize，再包一层 zapcore.WriteSyncer：

Golang Naming

Go（Golang）命名规范 — 包括包、构造函数、结构体、接口、常量、枚举、错误、布尔值、接收器、getter/setter、函数等。

下载

lj := &lumberjack.Logger{
    Filename:   "app.log",
    MaxSize:    100, // MB
    MaxBackups: 7,
    MaxAge:     28,  // days
    Compress:   false, // 关闭内置压缩，自己控制
}
core := zapcore.NewCore(
    zapcore.NewJSONEncoder(zap.NewProductionEncoderConfig()),
    zapcore.AddSync(lj), // 直接传 lj，它实现了 WriteSyncer
    zap.InfoLevel,
)

注意：lumberjack 的 Compress: true 会在 Rotate 后立即同步压缩，同样会卡写入，所以设为 false，后续靠异步 goroutine 补上。

按天切割时如何避免午夜流量高峰引发多文件竞争？

如果设置 MaxAge: 1 并依赖 lumberjack 的定时检查，它默认每分钟扫一次，可能在 00:00:01～00:00:59 之间任意时刻触发切割，此时若刚好有 10 个请求并发写日志，可能产生多个 goroutine 同时尝试 Rename 同一个文件，Linux 下虽 rename 是原子的，但 lumberjack 内部没加锁，可能误判切割状态。

更稳的方式是放弃 MaxAge，改用「按名切割」+ 主动触发：