Go 程序退出前日志偶尔丢失怎么办：缓冲写入、Flush 与 defer 收尾检查

批处理程序跑完后，终端显示“写入完成”，但打开 run.log，最后几十行偶尔不见了。这个现象通常不是 fmt.Fprintf 随机失效，而是日志先进入了 bufio.Writer 的内存缓冲，程序在真正落盘前就结束了。只要把“写入成功”和“收尾成功”分开检查，问题就能稳定复现和修好。

最后几行为什么总在进程结束时消失

先看一个容易误判的最小写法：

f, err := os.Create("run.log")
if err != nil {
    return err
}
defer f.Close()

w := bufio.NewWriter(f)
for _, line := range lines {
    if _, err := fmt.Fprintln(w, line); err != nil {
        return err
    }
}
return nil

这里每次 Fprintln 写的是 w，不是直接写文件描述符。只要缓冲区还没满，内容就停在 bufio.Writer 内部；函数返回时，defer f.Close() 只关闭底层文件，并不会替你调用上层 writer 的 Flush。因此，短日志更容易暴露这个问题：它们恰好没有把缓冲区填满。

程序退出前日志偶尔丢失，基本都是日志库用了缓冲写入、进程收到信号直接强制终止、或者 defer 里的 Flush 没来得及执行三类场景，不用全量替换日志库，先把缓冲刷盘逻辑和退出信号绑定，再补一层收尾检查，绝大多数场景都能解决。

一次退出故障的时间线

把现场按时间顺序拆开，通常会得到下面这条链路：

1. 业务循环逐行调用 fmt.Fprintln(w, line)，调用返回且没有报错。
2. 缓冲区没有达到容量，最后一批内容仍在用户态内存。
3. 函数返回，底层 *os.File 执行 Close。
4. 进程退出，尚未从 w 刷出的尾部日志没有机会再写出去。

这也是为什么“把 defer f.Close() 写上了”仍然不够。defer 的执行时机是外层函数返回时，而不是每个包装对象都自动完成收尾。若把 writer 放在一个更长生命周期的函数里，延迟执行还会更明显。

修复时先 Flush，再关闭文件

修复的关键是让拥有缓冲区的对象负责刷新，并把刷新错误传回调用方。一个小的日志写入函数可以这样写：

func writeLog(path string, lines []string) (err error) {
    f, err := os.Create(path)
    if err != nil {
        return err
    }

    w := bufio.NewWriter(f)
    defer func() {
        if closeErr := f.Close(); err == nil && closeErr != nil {
            err = closeErr
        }
    }()

    for _, line := range lines {
        if _, err = fmt.Fprintln(w, line); err != nil {
            return err
        }
    }
    if err = w.Flush(); err != nil {
        return err
    }
    return nil
}

这里有两个容易漏掉的细节。第一，Flush 放在所有写入之后，不能只在“写入超过缓冲大小”时调用。第二，匿名返回值 err 让关闭错误有机会被保留；如果前面已经有更具体的写入或刷新错误，就不要用一个后发生的关闭错误把它覆盖掉。

Flush、Close 和 Sync 各自解决什么问题

Flush 负责把 bufio.Writer 的内存内容交给底层 writer。对这里的 *os.File 来说，它完成的是“缓冲层到文件写入层”的推进。

Close 负责关闭文件对象，并可能暴露底层写入的错误，所以它的返回值不能无条件丢弃。但它不应该被当成任意上层缓冲包装器的通用刷新动作；写入链上有几个缓冲层，就要明确每一层的结束责任。

Sync 的语义更靠后：它请求操作系统把文件当前内容提交到稳定存储。日志工具若只是希望退出前不丢掉 writer 缓冲，先正确 Flush 和 Close 就够了；只有数据耐久性本身是需求时，才在刷新后评估 Sync 的额外成本。

不要用 os.Exit 绕过收尾路径

另一个常见现场是：主函数发现错误后直接调用 os.Exit(1)。这会让当前 goroutine 中已经登记的 defer 不再按普通返回路径执行，缓冲 writer 和文件都可能来不及收尾。

更稳妥的做法是让业务函数返回错误，在 main 的最外层统一打印并设置退出状态：

func main() {
    if err := run(); err != nil {
        fmt.Fprintln(os.Stderr, err)
        os.Exit(1)
    }
}

run 内部完成 Flush 和 Close，这样失败路径和成功路径都经过同一套收尾逻辑。若必须在库代码里终止进程，更应该先确认没有待刷新的 writer。

用一个可重复的验收场景收口

不要只在日志量很大时测试。准备 3 行短文本，让总长度明显小于 writer 的默认缓冲容量；连续运行几百次，再检查文件最后一行是否始终存在。随后人为让目标目录不可写，确认 Flush 或 Close 的错误能够被测试捕获。

如果日志由多个 goroutine 产生，不要让它们直接共享一个没有同步保护的 writer。可以让一个专门的写入 goroutine 独占文件，其他 goroutine 通过 channel 发送日志；程序退出时先停止生产，再关闭 channel，写入 goroutine 消费完毕后执行 Flush 和 Close。否则即使单线程收尾写对了，退出竞态仍可能截断最后一批消息。

相关问题：为什么有时只丢一小段尾日志

Write 返回 nil 是否代表数据已经落盘？

不代表。它只说明当前写入调用没有报告错误；如果目标是 bufio.Writer，数据可能还在内存缓冲中。需要在生命周期结束时显式检查 Flush。

每写一行都 Flush 可以吗？

可以，但会增加系统调用和写入开销。普通批量日志更适合按批次刷新；需要实时观察时，可以使用专门的行缓冲策略，并用压测确认吞吐和延迟。

关闭文件后还能补 Flush 吗？

不应这样设计。先刷新上层 writer，再关闭底层文件，顺序更清晰，也能把每一步的错误单独记录下来。