直接写文件比 bufio.Writer 慢因每次 Write 可能触发系统调用，而 bufio.Writer 通过缓冲减少 syscall 次数；但必须显式 Flush() 保证数据写出，且需检查错误，defer 不可靠，缓冲区大小需依场景调整，非万能优化。
为什么直接写文件比用 bufio.Writer 慢得多
因为每次调用 os.File.Write() 都可能触发一次系统调用，而系统调用开销远高于内存操作。尤其在写小块数据（比如逐行写日志、拼接字符串）时，频繁 syscall 会显著拖慢性能。bufio.Writer 把多次小写入攒成一块，等缓冲区满或显式 Flush() 时才真正落盘。
bufio.Writer 必须手动 Flush() 才能保证数据写出
这是最常被忽略的坑：不调 Flush()，程序退出前缓冲区里的内容可能根本没写到磁盘——尤其是用 defer writer.Flush() 时，如果 main() 提前返回或 panic，defer 不会执行。
- 写完必须显式调
writer.Flush()，且要检查返回错误：if err := writer.Flush(); err != nil { /* handle */ } - 不要依赖
defer在函数退出时“自动”刷，除非你 100% 确保函数正常结束且无 panic - 若写入后立即关闭文件，
Close()会内部调Flush()，但只对*os.File有效；若包装了其他io.Writer（如网络连接），Close()不一定刷缓冲
缓冲区大小设太小或太大都影响效果
默认缓冲区是 4KB（bufio.DefaultWriterSize），对大多数场景够用。但需根据实际写入模式调整：
- 写大量短行（如 CSV 行），缓冲区太小会导致频繁 flush，失去缓冲意义；可设为 64KB 或 128KB
- 写超大单条数据（如一个 10MB JSON），缓冲区再大也没用，因为
Write()会直接 bypass 缓冲区走底层写（见bufio.Writer源码中的largeWrite判断） - 内存受限环境（如嵌入式），避免盲目设大缓冲，防止 goroutine 堆栈或 GC 压力突增
创建示例：writer := bufio.NewWriterSize(file, 64*1024)
立即学习“go语言免费学习笔记（深入）”；
别把 bufio.Writer 当万能加速器用在错误场景
它只优化「多次小写入 → 少次大写入」，不是所有 IO 都适合加缓冲：
- 写实时日志（需每条立刻可见），加缓冲反而导致延迟，应禁用或设极小缓冲+每行后
Flush() - 写网络 socket 时，对方协议要求严格顺序/及时响应（如 HTTP chunked response），缓冲可能打乱节奏
- 底层 writer 本身已带缓冲（如某些数据库驱动、加密 writer），再套
bufio.Writer可能冗余甚至出错 - 并发写同一
bufio.Writer实例会 panic — 它不是线程安全的，多 goroutine 写需加锁或每个 goroutine 独享一个
缓冲区解决的是 syscall 频率问题，不是磁盘瓶颈本身。如果磁盘 IOPS 已饱和，加缓冲只会让数据在内存里堆得更高，最后 flush 更卡。
