Go Lumberjack 怎样在主动轮转后继续写入日志

主动轮转后继续写日志，关键是保留同一个 Lumberjack 实例：先调用它的 Rotate() 并检查返回错误，成功后继续使用原来的日志器写入即可。Rotate 会关闭当前文件、将已有活动文件改为带时间戳的备份名，并以原 Filename 创建新的活动文件；上层日志器仍持有原来的写入对象。

Lumberjack 官方项目：https://github.com/natefinch/lumberjack

现有能力：切换内部文件，不替换上层日志器

本文讨论的是 Lumberjack v2 的现有主动轮转接口。它适合在应用定义的控制动作中切分日志，例如维护操作或批次切换，不必等文件达到 MaxSize 才触发。

需要区分两个身份：日志器保存的输出对象是 Lumberjack；Lumberjack 内部保存的才是当前文件句柄。Rotate 改变的是内部文件状态，因此不需要每次重新创建 log.Logger，也不需要把新文件句柄重新安装到日志器里。

结构上，业务日志器和 Lumberjack 属于写入对象组，Filename、活动文件和时间戳备份属于文件归属组，Rotate 属于控制入口组。Filename 指定持续使用的活动路径，备份是旧文件的另一个名称，而不是以后继续追加的目标。

为什么需要主动轮转接口

直接在应用外把文件重命名，已经打开的句柄不一定自动指向新路径下创建的文件。让 Lumberjack 自己执行轮转，可以把关闭旧句柄、处理备份名称和打开新文件交给同一资源所有者，减少应用同时维护两套文件状态的机会。

这也解释了为什么不应把外部轮转器与 Lumberjack 随意叠加到同一活动文件上。官方说明假定一个进程负责这组文件；多个进程、多个独立实例共写一个 Filename，会超出同一个对象内部协调能力。

对已有代码的影响：持有同一实例，并传播错误

如果已有代码使用 log.New 把输出绑定到 Lumberjack，只需让负责轮转的组件取得同一个实例，再调用 Rotate。应在初始化时确定 Filename 和保留策略，不要在持续写入时直接修改公开字段来尝试动态切换路径。

最需要补上的通常是错误处理。Rotate 返回错误时，可能是关闭、改名或创建新文件过程中失败，不能假定全部步骤均未发生，也不能假定已经拥有可写的新活动文件。错误应交给独立出口或上层控制逻辑，结合文件系统状态决定后续恢复。

接入示例：轮转前后复用一个 logger

下面的完整示例记录两条带不同标记的文本，中间主动轮转一次。它使用标准 log 包的 Output 方法接收写入错误；收尾用 errors.Join 保留错误，需要 Go 1.20 或以上版本。示例只用于说明写入归属，没有后台业务协程。

package main

import (
    "errors"
    "fmt"
    "log"
    "os"
    "path/filepath"

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

func run() (err error) {
    filename := filepath.Join("logs", "app.log")
    // 预建专用目录；示例不会修改目录中其他用途的文件。
    if err := os.MkdirAll(filepath.Dir(filename), 0700); err != nil {
        return fmt.Errorf("创建日志目录: %w", err)
    }
    sink := &lumberjack.Logger{
        Filename:   filename,
        MaxSize:    64, // 单个活动文件的大小上限，单位为 MB。
        MaxBackups: 4,
        MaxAge:     7, // 旧备份的保留天数规则。
        Compress:   true,
    }
    defer func() {
        // 业务不再写入后关闭当前文件，并保留关闭错误。
        err = errors.Join(err, sink.Close())
    }()

    // 日志器只创建一次，持有的是 Lumberjack 写入对象。
    logger := log.New(sink, "demo ", log.LstdFlags|log.Lmicroseconds)
    if err := logger.Output(1, "演示记录：主动轮转之前"); err != nil {
        return fmt.Errorf("写入轮转前记录: %w", err)
    }
    // 由同一个对象关闭旧句柄、归档旧文件并创建新的活动文件。
    if err := sink.Rotate(); err != nil {
        // 失败后不声称已经切换成功，直接交给调用方处置。
        return fmt.Errorf("主动轮转失败: %w", err)
    }
    // 不重新构造 logger，也不替换它的输出对象。
    if err := logger.Output(1, "演示记录：主动轮转之后"); err != nil {
        return fmt.Errorf("写入轮转后记录: %w", err)
    }
    return nil
}

func main() {
    if err := run(); err != nil {
        // 故障交给独立出口，避免继续依赖可能失败的日志文件。
        fmt.Fprintln(os.Stderr, err)
        os.Exit(1)
    }
}

独立目录可以按下面的方式准备依赖并运行。代码和命令在本文中未执行，不提供伪造的控制台或文件截图。

# 在独立示例目录初始化模块；已有模块不需要再次初始化。
go mod init example.com/rotatedemo
go get gopkg.in/natefinch/lumberjack.v2

# 保存 main.go 后执行，程序会在当前目录使用 logs/app.log。
go run .

# 自行查看活动文件和备份列表；本文不把这些命令描述为已执行。
ls ./logs
cat ./logs/app.log

代码的核心不是等待一段时间再重新打开文件，而是 logger 从始至终使用同一个 sink。成功的 Rotate 已经创建新活动文件，后续 Output 调用自然交给该实例的 Write。

并发、缓冲与后台归档的边界

同一个 Lumberjack 实例的 Write 和 Rotate 使用内部互斥锁协调文件状态。不过，这不等于业务层已经建立了精确的批次分界。多个协程同时记录日志时，谁先取得锁会影响具体记录进入旧文件还是新文件；若要求某个批次所有记录都进入同一文件，应用还需要暂停、等待或其他明确的业务协调。

可以把同一日志器、同一 writer 放在对象持有组，把 Write、Rotate、互斥锁放在文件操作组，再把后台清理单独分组。Write 与 Rotate 共用对象内部的锁，后台清理负责后续归档维护，不能把两者误认为一个同步完成的业务事务。

如果上层额外套了 bufio.Writer 或其他缓冲器，缓存中的字节尚未进入 Lumberjack。要求这些字节归入旧文件时，应先协调停止或暂停写入、刷新缓冲，再调用 Rotate；仅 Rotate 无法替上层缓冲器决定数据归属。示例没有额外缓冲层。

Compress、MaxBackups 和 MaxAge 会影响备份的后续压缩与清理。Rotate 会启动相关处理，但其成功返回不能当作所有压缩归档工作已经完成的证明。也不要高频循环调用 Rotate，把它当作按毫秒切文件的工具。

预期归属和常见疑问

Rotate 后是否还要调用 Close 再重新创建实例？

正常成功轮转不需要这样做。Rotate 本身已经处理活动文件切换；Close 应用于资源收尾，而不是每次轮转之后的必做动作。

Close 能保证其他协程以后绝不会再写文件吗？

不能把关闭当前句柄当作应用停止协议。Lumberjack 的写入逻辑在内部没有打开文件时可以尝试打开文件，因此必须由应用先结束写入者，再执行收尾。

为什么活动日志路径没有变？

固定 Filename 便于后续记录使用同一入口；变化的是旧文件的备份名称和内部句柄。日志采集器如果跟踪备份与当前文件，也需要按自己的文件发现规则配置。

参考：Rotate API、项目维护文档、v2 文件管理实现。