Go bufio.Writer 写文件后为什么必须 Flush

用 bufio.NewWriter(file) 写文件时，Write 或 WriteString 成功，并不等于目标文件已经收到全部字节。它们先把数据放进 bufio.Writer 的内存缓冲；只有写入结束时调用 Flush()，剩余内容才会交给底层的 *os.File。因此，短内容尤其容易“看起来没问题”：缓冲区没有溢出，程序又很快结束，尾部数据就可能仍未提交。

文件写入的可靠结束边界是“全部写入完成 → 检查 Flush → 再关闭文件”。Flush 解决的是 bufio 层的缓冲提交；如果还要求更强的物理持久化语义，则要另外评估 File.Sync。

先分清 bufio.Writer 和文件句柄各自负责什么

bufio.Writer 是包在 io.Writer 外面的缓冲层。应用拿到的是一个 Writer，文件句柄是它的底层目标，中间还有一块由 Writer 管理的内存。调用 w.WriteString("hello") 时，数据可能只停留在这块内存里；调用 w.Buffered() 可以观察当前缓冲区中已有多少字节。

把 Flush 放在所有写入之后并检查返回错误

把 Flush 当成一个明确的结束动作，代码会更容易审查：前面只负责构造内容，最后一次性提交缓冲，并把错误交给调用方。写入阶段也不要忽略返回值，因为底层出错后，Writer 后续写入和 Flush 都可能继续返回同一个错误。

package main

import (
    "bufio"
    "fmt"
    "os"
)

func saveReport(path string, lines []string) (err error) {
    // 文件句柄负责底层写入，Writer 负责聚合小块数据。
    file, err := os.Create(path)
    if err != nil {
        return err
    }
    defer func() {
        // Close 错误也要保留，不能覆盖前面已经出现的错误。
        if closeErr := file.Close(); err == nil {
            err = closeErr
        }
    }()

    writer := bufio.NewWriter(file)
    for _, line := range lines {
        // 每行写入都检查结果，避免只检查最后的 Flush。
        if _, err = fmt.Fprintln(writer, line); err != nil {
            return err
        }
    }
    // 所有内容写完后提交 Writer 的剩余缓冲。
    if err = writer.Flush(); err != nil {
        return err
    }
    return nil
}

这个写法的关键不是把 Flush 写成固定模板，而是让它处在“最后一次写入”和“关闭文件”之间。若 Flush 失败，函数会立即返回；命名返回值让延迟关闭逻辑仍能补充 Close 的失败信息。

文件 Close 不能替代 bufio.Writer.Flush

常见反例是只写 defer file.Close()，然后把 bufio.NewWriter(file) 当作普通文件使用。这里有两个对象、两种状态：Close 管理的是 *os.File，而未提交的数据仍由 bufio.Writer 持有。关闭底层句柄之前没有 Flush，就把结束顺序交给了偶然条件。

// 反例：只关闭文件，未提交 Writer 的尾部缓冲。
file, err := os.Create("report.txt")
if err != nil {
    return err
}
defer file.Close()

writer := bufio.NewWriter(file)
_, _ = writer.WriteString("最后一小段内容") // 可能仍在 Writer 缓冲区
// 这里缺少 writer.Flush()

短内容更容易掩盖问题，因为它可能没有触发缓冲区自动写出；换成较大的内容或改变运行时机，现象又可能消失。正确做法是显式维护两层生命周期：先处理 writer.Flush()，再处理 file.Close()。如果 Writer 在更早的写入中已经记录错误，Flush 也不会把它“修好”。

用一张结束清单判断文件是否真的写完

“写完”要先说清楚是哪一层写完。对大多数导出文件，检查每次写入、调用 Flush、再关闭文件已经能覆盖应用层最常见的遗漏。若业务要求断电后也尽量保留内容，则还要考虑 file.Sync()；它是文件对象向稳定存储推进的另一项要求，不能把它和 Flush 混为一谈。

常见问题

bufio.Writer 写入很少的数据也必须 Flush 吗？

必须。数据量小只能说明更容易留在缓冲区，不能说明它一定已经交给底层文件。

Flush 成功后还要 Close 吗？

通常要。Flush 与关闭是不同生命周期动作；Flush 不会替你释放文件句柄。

Flush 成功是不是代表数据已经写入磁盘？

不等于。Flush 的语义是写给底层 io.Writer；需要更强持久化保证时，结合文件系统和业务要求评估 File.Sync。

把 bufio.Writer 看成需要显式提交的缓冲层，文件写入的判断就不会停留在“函数返回了 nil”。真正稳妥的结束清单是：写入错误可见、Flush 错误可见、Close 错误不被吞掉；只有在业务确实需要时，再为稳定存储语义增加 Sync。