应使用 bufio.Writer 而非 os.File.Write 进行小数据写入，因其可将多次写合并为少数系统调用；默认 4KB 缓冲适合多数日志场景，需手动 Flush() 保证数据落盘，并发写需单协程+channel 模型，实时性要求高或短生命周期程序则应绕过缓冲。
直接用 os.File.Write 写小数据，每写一次就触发一次系统调用——这不是慢，是“自废武功”。真正该做的，是用 bufio.Writer 把成百上千次写合并成几次落盘。
为什么 os.File.Write 会拖垮性能
每次调用 os.File.Write，Go 都把传入的 []byte 直接扔给内核 write() 系统调用。哪怕只写 8 个字节，也得切换用户态/内核态、进调度队列、等 I/O 完成。在日志打点、指标上报这类高频小写入场景下，CPU 时间全花在 sys_enter_write 上，业务逻辑反而卡着不动。
常见错误现象：
-
strace -e write显示写了 10 万行，就触发了近 10 万次write() -
iostat -x 1中%util接近 100%，但实际吞吐很低 - 程序退出后文件内容少了一截——因为没
Flush()
bufio.Writer 的缓冲行为与关键参数
bufio.Writer 在内存里维护一块缓冲区，写操作先填这里；只有缓冲满、显式调用 Flush()、或关闭文件时，才真正发系统调用。
立即学习“go语言免费学习笔记（深入）”；
必须注意的几点：
-
bufio.NewWriter(f)默认用 4096 字节缓冲，对平均行长100字节的日志来说，每 40 行才刷一次盘，效果立竿见影 -
bufio.NewWriterSize(f, 64*1024)是多数场景的甜点值；超过1MB容易导致延迟升高，且无收益 -
Flush()必须手动调用——panic、os.Exit()或提前 return 都会让最后一块缓冲数据永远留在内存里 - 如果写完要立刻被其他进程读到（比如 watchdog 检查），仅
Flush()不够，还得f.Sync()
并发写同一文件时的典型陷阱
多个 goroutine 共享一个 *bufio.Writer 会引发竞态：内部缓冲区、偏移量、错误状态都不是并发安全的。加 sync.Mutex 锁整个写过程，又容易变成单点瓶颈。
更合理的做法是：
- 用
chan []byte+ 单写协程模型：所有生产者发数据到 channel，唯一消费者用bufio.Writer批量写入 - channel 缓冲大小设为
1000–10000，避免内存暴涨或阻塞过久 - 写协程退出前，务必
close(ch)并在循环后调用wr.Flush()，否则最后一段内容滞留 - 别用
log.SetOutput直接设为bufio.Writer——log包内部不保证调用Flush()
什么时候不该用 bufio.Writer
不是所有场景都适合缓冲。以下情况应绕过或慎用：
- 写入后需严格实时落盘（如金融交易日志），缓冲会引入不可控延迟
- 写入内容极不规则，且单次写入已接近或超过缓冲区大小，缓冲反而增加拷贝开销
- 程序生命周期极短（如 CLI 工具秒级退出），没机会触发
Flush()，不如直接裸写 - 目标文件是管道（
/dev/stdout）或 socket，内核本身已有缓冲机制，再套一层可能适得其反
缓冲区大小、Flush() 时机、并发模型这三者必须一起看——调大缓冲却忘了 Flush()，或用了 channel 却没关它，数据就静默消失了。这不是配置问题，是数据可靠性边界问题。
