Go Lumberjack MaxSize 为什么不是日志目录总大小限制

先说结论：MaxSize 只限制 Lumberjack 当前正在写入的那一个日志文件，单位是 MB；它不会把同一目录里的当前文件、历史备份和其他日志相加后限制为一个总数。目录占用要同时看 MaxBackups、MaxAge、压缩文件，以及目录中是否还有别的程序生成的文件。

官方地址：https://github.com/natefinch/lumberjack

先确认 MaxSize 实际限制的对象

Lumberjack 的 Filename 是当前文件名。写入前，如果当前文件已经达到上限，或者本次写入会让它超过上限，库会关闭当前文件、改名为带时间戳的备份，再创建一个仍使用原始文件名的新文件。因此，MaxSize: 100 的含义是“单个活跃日志文件大约不超过 100 MB”，不是“这个目录最多 100 MB”。

还有一个容易忽略的边界：如果单次 Write 本身大于 MaxSize，Lumberjack 会返回错误，而不是把这次超大写入拆成多个备份。也就是说，MaxSize 是轮转阈值，不是目录级配额，也不是任意大消息的分片器。

MaxBackups 和 MaxAge 才决定旧日志留多久

轮转以后，旧文件会留在同一个目录。MaxBackups 按可识别的旧文件数量限制保留数，MaxAge 按文件名中的轮转时间限制天数；两者都是 0 时，不会因为这两个参数主动删除旧日志。Compress 只改变旧文件的存储形式，不把多个文件合并成一个总量上限。

遇到“目录越来越大”时按三层检查

第一层只看 Filename 对应的当前文件：它接近 MaxSize 并不代表配置失效，下一次合适的写入才会触发轮转。第二层看文件名是否符合 Lumberjack 的时间戳备份格式，再对照 MaxBackups 和 MaxAge。第三层把目录里的其他扩展名、其他服务日志、手工复制文件和未由当前 Logger 管理的文件单独列出。

不要用“目录总大小超过 MaxSize”作为判断轮转失败的证据。更有用的证据是：当前文件是否仍用原始名称、旧文件是否是同一 Filename 生成的时间戳备份、轮转后清理是否发生，以及目录中是否混入了别的来源。

用组合配置控制文件生命周期

package main

import (
    "log"

    "gopkg.in/natefinch/lumberjack.v2"
)

func main() {
    log.SetOutput(&lumberjack.Logger{
        Filename:   "/var/log/myapp/app.log",
        MaxSize:    100, // 单个当前文件达到约 100 MB 后轮转
        MaxBackups: 7,   // 最多保留 7 个可识别的旧备份
        MaxAge:     14,  // 轮转时间超过 14 天的旧备份可被清理
        Compress:   true, // 只压缩旧备份，不改变 MaxSize 的含义
    })

    // 真实项目中继续使用 log.Printf 等写入接口即可。
    log.Println("service started")
}

这段配置的职责边界很清楚：Lumberjack 负责单文件轮转和它能识别的旧备份清理；如果业务要求“目录总量不能超过某个字节数”，还需要在外层定时任务或日志采集系统中统计目录并删除、迁移或限流。不要把 MaxBackups: 7 解释成总大小上限，因为每个备份的实际大小可能不同，压缩后的大小也无法在配置时精确预估。

常见问题速查

为什么 MaxSize 设置为 100，目录仍然超过 100 MB？

因为 100 MB 只对应当前文件。历史备份、压缩包和目录中的其他文件都可能继续占用空间。

把 MaxBackups 设置为 1 就能保证目录只有一个文件吗？

不能。它只约束 Lumberjack 识别到的旧备份数量，当前文件始终存在，其他来源的文件也不受约束。

怎样实现真正的目录总量限制？

保留 Lumberjack 的轮转配置，再由外层策略按字节统计整个目录，对非当前文件做迁移或清理，并明确排除不属于该 Logger 的文件。

记住一句话：MaxSize 管“单个当前文件何时换代”，MaxBackups 和 MaxAge 管“旧备份留多少、留多久”，目录总量则需要目录级策略单独负责。