bufio.writer.flush() 是唯一可靠的手动刷新方式，数据仅在缓冲区满、显式调用 flush() 或 writer 被垃圾回收时写入底层文件；file.close() 不保证缓冲区清空，必须在 write 后、close 前显式调用 flush()。
bufio.Writer.Flush() 是唯一可靠的手动刷新方式
Go 中没有“自动刷新缓冲区”这回事，bufio.Writer 的数据只有在三种情况下才会真正写入底层文件：缓冲区满、显式调用 Flush()、或 Writer 被垃圾回收（不可靠且不推荐依赖）。你不能靠 file.Close() 或程序退出来确保缓冲内容落盘——它只关文件描述符，不等缓冲区清空。
常见错误现象包括：文件看起来“写完了”，但最后一段内容缺失；日志行数对不上；程序崩溃后部分数据永久丢失。
-
Flush()必须在所有Write操作之后、file.Close()之前显式调用 - 如果写入中途发生错误（如磁盘满），
Flush()会返回该错误，需检查 - 多次调用
Flush()是安全的，但无必要；未满时触发一次系统调用，可能降低吞吐
bufio.Writer 的缓冲区大小影响 Flush 频率和延迟
默认 4KB 缓冲区在高频小写场景下会导致每写几 KB 就刷一次盘，既增加 syscall 开销，又让数据落地延迟不可控。而设得过大（如 1MB），又可能导致关键日志卡在内存里几十秒才落盘。
实际调整建议：
- 日志追加写：用
bufio.NewWriterSize(file, 32*1024)（32KB），平衡延迟与系统调用次数 - 批量导出 CSV/JSON：可设为
256*1024或512*1024，写完一次性Flush() - 交互式输出（如 CLI 工具实时反馈）：缓冲区设小（
1024），或干脆不用bufio，直接os.Stdout.Write()
高并发写同一文件时，Flush 不是瓶颈，同步才是
多个 goroutine 共享一个 bufio.Writer 并发写，即使加了 mutex，Flush() 也会成为串行点，性能反而比单协程差。这不是 Flush 本身慢，而是设计误用。
正确做法是：
- 每个 goroutine 独立使用自己的
bufio.Writer，写各自临时文件，最后用io.Copy合并 - 若必须写同一文件，用
sync.Pool复用Writer，并通过w.Reset(file)关联目标文件，避免重复分配 - 绝对不要在
Flush()前加锁保护整个写+刷流程——这等于把并发退化成串行
Flush 之后数据仍可能未写入磁盘物理扇区
Flush() 只保证数据从 Go 缓冲区提交到操作系统内核的页缓存（page cache），不等于落盘。断电或内核崩溃时，这部分数据仍会丢失。
如需强持久性（例如金融交易日志），必须额外调用：
-
file.Sync()—— 强制将内核页缓存刷入磁盘（代价高，慎用） - 打开文件时加
os.O_SYNC标志（每次写都同步，性能极差，仅用于极低吞吐关键路径） - 生产环境更常用的是“定期
Sync()+ 定长日志 + 校验机制”，而非每次Flush()都跟Sync()
最容易被忽略的一点：很多人以为 Flush() = 数据安全，其实它只是从 Go 内存交到了 OS 手里，后面还有两道关卡——OS 缓存和磁盘控制器缓存。真要保命，得主动过这三关。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
