Go bufio.Writer 写入成功但文件没有内容怎么办

先确认是否在关闭底层文件之前调用了 bufio.Writer.Flush，并检查它返回的错误。Write 或 WriteString 成功，可能只是数据进入了 Go 的写缓冲，还没有提交给文件。只调用 file.Close 不会替 bufio.Writer 刷新。

例如导出一份只有几行的小报表，写入调用没有报错，但打开文件仍为空。这类场景优先检查缓冲层的收尾，而不是立即修改文件权限。下面围绕这个场景说明写法，没有声称实际运行或发生过线上事故。官方文档地址：https://pkg.go.dev/bufio#Writer。

写入成功只说明当前调用没有报错

包装关系是“调用方使用 bufio.Writer，bufio.Writer 持有底层 os.File”。写缓冲区属于前者，不属于后者。短数据可以全部留在缓冲区；Buffered 返回尚在当前缓冲中的字节数，能帮助解释为何文件内容尚不可见。

这不是 bufio 的新规则，也不是某个版本突然改变了 Write 的含义。需要改变的是应用的成功判定：从“写入调用返回 nil”调整为“写入、刷新以及由当前函数负责的关闭都没有报错”。大数据有时会触发刷新或直接交给底层，因此“大文件正常、小文件为空”不能排除同一个收尾缺口。

只关闭文件的旧写法漏掉了缓冲区

下面片段假定 f 已经打开且由当前函数管理，展示问题而不是建议读者照抄：

// 反例：只安排底层关闭，既没有刷新，也没有检查关闭错误。
defer f.Close()
w := bufio.NewWriter(f)
if _, err := w.WriteString("订单号,金额\n"); err != nil {
    return err
}
return nil // 缺少 w.Flush，不能据此判断文件已收到全部数据。

f 不知道还有哪个包装对象缓存了内容。把 Close 放在 defer 里只解决资源释放，不解决缓冲提交。把 Flush 放到文件已经关闭之后也不正确：有待写数据时，它要调用底层写入，面对的是一个已关闭的文件。

也不要只是加 defer w.Flush() 就结束。defer 能安排调用，但裸调用的错误会丢失；多个 defer 又是后注册先执行，代码调整后可能把刷新和关闭的顺序反过来。

把 Flush 放在关闭前并保留所有错误

以下是完整的包级函数，适用于 Go 1.20 及以上，因为使用了 errors.Join。为避免示例覆盖已有报表，采用 O_EXCL：路径已存在就报错；父目录必须已存在。函数正常返回 nil 时，所有数据已提交给底层文件且关闭成功，但不宣称已完成持久化。

package fileout

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

// WriteNewReport 创建新文件，不覆盖已有内容；失败可能留下部分文件。
func WriteNewReport(path string, rows []string) (err error) {
    f, err := os.OpenFile(path, os.O_WRONLY|os.O_CREATE|os.O_EXCL, 0600)
    if err != nil {
        return fmt.Errorf("创建报表: %w", err)
    }
    defer func() {
        // 具名返回值保留写入或刷新错误，同时加入关闭错误。
        if closeErr := f.Close(); closeErr != nil {
            err = errors.Join(err, fmt.Errorf("关闭报表: %w", closeErr))
        }
    }()

    w := bufio.NewWriter(f)
    for _, row := range rows {
        // 换行也是普通字节，不会自动触发按行刷新。
        if _, writeErr := w.WriteString(row + "\n"); writeErr != nil {
            return fmt.Errorf("写入报表: %w", writeErr)
        }
    }
    // 正常路径显式刷新，执行时文件仍未被 defer 关闭。
    if flushErr := w.Flush(); flushErr != nil {
        return fmt.Errorf("刷新报表: %w", flushErr)
    }
    return nil
}

这里用显式 Flush 让失败在正常控制流中可见，用 defer 确保每条返回路径都关闭文件。写入失败时不继续承诺报表完整；刷新失败也不能把返回值改成 nil。部分内容可能已进入文件，本函数不是事务写入，也不保证失败自动回滚。

若需求是“完整报表才替换正式文件”，需要另外设计临时文件和替换协议及平台相关持久化策略，不能把本例的排障修复误认为原子发布。旧工具链不支持 errors.Join 时，需自行保留主错误和关闭错误，不能为了兼容直接忽略后者。

Flush 与 Sync 对应不同保证

Flush 将当前缓冲字节交给底层 io.Writer；如果底层还有自有缓存，并不意味着所有层都已经刷新。这里底层是 os.File。File.Sync 针对已写到文件的内容请求稳定存储，不会看到仍留在 bufio.Writer 中的数据。

如果业务需要 Sync，在上例 Flush 成功之后、return nil 之前加入以下片段；仍让 defer 承担最后的 Close，并检查错误。普通“文件看不到短文本”的问题先修 Flush，不必无条件每写一行就 Sync。

// 可选：仅在明确要求文件内容持久化时加入，位置在 Flush 成功之后。
if syncErr := f.Sync(); syncErr != nil {
    return fmt.Errorf("同步报表: %w", syncErr)
}

File.Sync 的官方说明：https://pkg.go.dev/os#File.Sync。持久化要求还可能涉及文件名、目录项、替换动作和存储系统自身行为，本例不把一次 Sync 扩展为完整的崩溃一致性保证。

按缓冲、错误和路径检查剩余异常

若已经调用 Flush，继续对照三类证据：是否检查了 Flush 的实际返回值；是否刷新了真正参与写入的那个 Writer；读到的路径是不是本次打开的文件。相对路径随工作目录解释，编辑器查看的同名文件可能不在同一目录。

在单一所有者控制的 Writer 上，Flush 成功后且没有新写入，Buffered 应为 0。这只说明 bufio 没有待提交字节，不保证内容没有被另一个进程截断、覆盖，也不证明数据是业务期望的完整报表。并发使用时应把写入、刷新及关闭纳入同一个同步或所有权方案，不能一边写一边凭瞬时 Buffered 下结论。

标准实现会保存底层写错误；遇到错误后，后续 Write 和 Flush 会继续返回该错误。盲目重复 Flush 不能当成恢复协议。Reset 会丢弃未刷新的缓冲并清除错误，也不是“再试一次”的无损修复。相关实现可复制查看：https://go.dev/src/bufio/bufio.go。

写入换行符会立即刷新吗？

不会。bufio.Writer 不保证按行刷新，换行只是普通数据。若日志或交互协议要求立即可见，应在明确的消息边界刷新并检查错误。

为什么数据写多后文件又有内容？

缓冲空间不足或大写入可能让数据更早交给底层，掩盖最终 Flush 的遗漏。末尾仍可能留有少量数据，不能据此省略最终刷新。

程序用 os.Exit 退出，还会执行 defer 吗？

不会。成功路径应先完成写入函数并处理错误，再决定退出码；进程被强制终止也不能指望 defer 补写数据。os.Exit 契约见 https://pkg.go.dev/os#Exit。

修复后的结果判断应是函数返回成功、文件路径正确、读者在自己的环境读取到期望字节；本文列的是复核方法，不是已运行报告。核心修复始终是：先让写缓冲提交完成，再关闭由你负责的底层文件，并保留每一层的错误。