Go bufio.Writer 多层包装时如何确认 Flush 传到最底层

多层 bufio.Writer 最容易误判的地方，是把“外层缓存清空”当成“数据已经写到文件”。实际规则很简单：Flush() 只负责把当前 Writer 的缓冲交给它的底层 io.Writer。如果底层仍是另一个 bufio.Writer，还要继续对内层调用 Flush()；写入 os.File 后，若还关心崩溃后的持久化，再单独调用 Sync()。

Flush 为什么不会自动穿透所有 bufio.Writer

bufio.NewWriter(w) 返回的是一个新的缓冲 Writer，它把 w 当作普通的 io.Writer 使用。Flush 的职责是写出“当前对象”的缓冲，并不会探测底层对象是否也提供 Flush 方法。因此，多层包装时应把它看成一串独立的缓存边界。

还有一个容易踩的细节：NewWriterSize 在传入的对象本身是容量足够大的 *bufio.Writer 时可能直接复用它。为了研究真实的多层关系，示例使用不同缓冲区大小，避免“看起来包装了两层，实际仍是同一个指针”。

先外后内，并检查每一次 Flush 的错误

调用顺序应从最外层开始，再逐层走向底层。下面的结构故意使用 8 KiB 和 1 KiB 两种缓冲容量；每个代码块里的注释只标出关键边界，重点是观察两个 Buffered() 的变化。

package main

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

func main() {
    file, err := os.Create("output.txt")
    if err != nil {
        panic(err)
    }
    defer file.Close() // 关闭文件句柄；缓冲内容仍由 Flush 明确处理

    inner := bufio.NewWriterSize(file, 1024)       // 内层直接面对 os.File
    outer := bufio.NewWriterSize(inner, 8*1024)    // 外层写入内层，不自动调用内层 Flush

    if _, err = outer.WriteString("一行需要完整发送的文本\n"); err != nil {
        panic(err) // 写入错误会让后续 Flush 继续返回该错误
    }
    fmt.Println("before:", outer.Buffered(), inner.Buffered())

    if err = outer.Flush(); err != nil {
        panic(err) // 此时只确认外层缓存已交给 inner
    }
    fmt.Println("after outer:", outer.Buffered(), inner.Buffered())

    if err = inner.Flush(); err != nil {
        panic(err) // 这一步才把 inner 的缓存交给 file
    }
    fmt.Println("after inner:", outer.Buffered(), inner.Buffered())
}

代码中的两个 Flush 都不能省略。若只执行 outer.Flush()，外层的 Buffered() 可能已经变成 0，但数据只是进入 inner；进程随后退出时，内层缓存仍可能没有写入文件。生产代码不要忽略 Flush 的返回值，因为底层写入失败后，后续写入和 Flush 也会继续返回错误。

用 Buffered 和底层计数器确认数据到了哪一层

检查文件内容并不适合作为唯一证据：文件可能已经存在旧内容，或者操作系统仍在缓存写入。更稳妥的办法是在最底层放一个只负责统计的 countingWriter，再结合各层 Buffered() 观察边界。

type countingWriter struct {
    writes int
    bytes  int
}

func (w *countingWriter) Write(p []byte) (int, error) {
    w.writes++              // 记录底层 Write 被调用的次数
    w.bytes += len(p)       // 记录真正交给底层的字节数
    return len(p), nil      // 本示例不模拟失败，生产代码仍须检查 Flush 错误
}

func verifyLayers() error {
    sink := &countingWriter{}
    inner := bufio.NewWriterSize(sink, 4)
    outer := bufio.NewWriterSize(inner, 16)

    if _, err := outer.WriteString("abcdef"); err != nil {
        return err // 先处理 Write，避免用不完整数据继续观察
    }
    if outer.Buffered() == 0 {
        return fmt.Errorf("outer buffer is unexpectedly empty")
    }
    if err := outer.Flush(); err != nil {
        return err // 外层归零不等于 sink 已收到数据
    }
    if sink.writes != 0 {
        return fmt.Errorf("inner buffer was expected to remain")
    }
    if err := inner.Flush(); err != nil {
        return err // 内层 Flush 后才检查底层写入计数
    }
    if sink.bytes != len("abcdef") {
        return fmt.Errorf("got %d bytes, want %d", sink.bytes, len("abcdef"))
    }
    return nil
}

这个验证的关键不是“写了几个字节”，而是三个状态要互相吻合：外层 Flush 后外层缓存归零；内层 Flush 前底层计数仍未增加；内层 Flush 后计数增加。这样就能证明 Flush 没有跨越内层缓冲自动传播。

Flush 完成后，什么时候还需要 file.Sync

写入普通文件时，完整收尾通常是“最外层到最内层依次 Flush，再对文件 Sync”。Flush 负责把 Go 进程内的缓冲交给 os.File；Sync 是向操作系统请求把文件内容同步到稳定存储的另一层动作。如果只是生成临时日志，Flush 往往已经满足读取方需求；如果是账单、索引或恢复点，就应根据可靠性要求处理 Sync 的错误。

if err := outer.Flush(); err != nil {
    return err // 先清空最外层缓冲
}
if err := inner.Flush(); err != nil {
    return err // 再清空直接连接文件的缓冲
}
if err := file.Sync(); err != nil {
    return err // 需要持久化语义时再请求同步到存储
}

如果层数会变化，可以把所有 Writer 作为明确的结构成员保存，并写一个从外到内的收尾函数；不要试图通过 io.Writer 接口反射查找 Flush。接口只承诺 Write，显式持有每一层才是可读、可测试的做法。

常见问题

只调用最外层 Flush，程序正常退出也安全吗？

不安全。只要底层还有一个 bufio.Writer，最外层清空后数据仍可能停留在内层；应逐层 Flush 并检查错误。

Buffered() 为 0 就代表文件里一定有数据吗？

不代表。它只描述被调用对象当前缓存的字节数，不能证明下层 Write 已执行，更不能证明已经持久化。

关闭 os.File 能代替 Flush 吗？

不能把它当成可靠替代。bufio.Writer 没有自动随文件关闭而递归 Flush 的保证，应先 Flush，再关闭文件。

NewWriterSize 为什么有时没有形成新的一层？

当传入对象是容量足够的 *bufio.Writer 时，标准库可能复用它。需要独立层时使用不同容量，并通过每层 Buffered 或指针关系确认结构。

官方参考：https://pkg.go.dev/bufio、https://pkg.go.dev/os。