直接用os.WriteFile不适合高频小写入，因其每次调用都触发一次系统调用，开销远超实际写入成本；应改用bufio.Writer缓冲合并写入，减少用户态/内核态切换。
为什么直接 os.WriteFile 不适合高频小写入
当你频繁调用 os.WriteFile 或 file.Write 写入小块数据（比如每条日志 100 字节），每次都会触发系统调用，陷入内核，开销远超实际写入成本。这不是 Go 的问题，是 POSIX I/O 的共性——没缓冲，就等于裸奔。
真正该用缓冲的场景：日志追加、流式生成文件、网络响应体拼接、CSV 行写入等持续小粒度输出。
-
os.WriteFile是原子性覆盖写，不支持追加缓冲，也不复用底层file句柄 - 单次
file.Write调用仍会走系统调用，除非你手动聚合字节 - 缓冲区大小不是越大越好：默认
bufio.Writer是 4KB，写入量小时反而增加延迟；超过 64KB 可能导致 GC 压力或内存浪费
用 bufio.Writer 包裹 *os.File 的标准做法
核心就是把原始 *os.File 丢给 bufio.NewWriter 或 bufio.NewWriterSize，后续所有写都走它。别忘了最后 Flush()，否则内容可能卡在内存里。
file, _ := os.OpenFile("out.log", os.O_CREATE|os.O_WRONLY|os.O_APPEND, 0644)
defer file.Close()
writer := bufio.NewWriterSize(file, 8192) // 显式设 8KB 缓冲
defer writer.Flush() // 必须放 defer，但注意：panic 时可能不执行
writer.WriteString("start: ")
writer.WriteString(time.Now().String())
writer.WriteByte('\n')
writer.Flush() // 立即落盘（可选，取决于是否需强一致性）
- 不要对同一个
*os.File同时用bufio.Writer和裸Write，会破坏缓冲状态甚至导致错位 -
bufio.NewWriter用默认 4KB，bufio.NewWriterSize才可控；传 0 会 panic -
defer writer.Flush()在函数退出时刷一次，但如果中间多次写入并需确保某次落地（如关键日志），得手动Flush()
何时该自己控制 Flush 时机
缓冲的本质是「攒够再发」，但业务常需要权衡延迟与吞吐：Flush 太少 → 数据滞留内存，进程崩溃就丢；Flush 太勤 → 失去缓冲意义，变回裸写。
立即学习“go语言免费学习笔记（深入）”；
- 日志场景：每条 ERROR 日志后
Flush()，INFO 可批量刷 - 导出 CSV：每写满 1000 行
Flush()，兼顾响应感和可靠性 - HTTP 响应体写入：通常交给
http.ResponseWriter自己管，你不用碰Flush；但若用io.Copy到bufio.Writer，就得留意源是否阻塞 -
Writer.Available()能查剩余缓冲空间，但一般没必要轮询；Writer.Buffered()返回已写未刷字节数，可用于监控积压
绕过 bufio 自己做缓冲的边界情况
极少数场景下，bufio.Writer 的行为不符合需求：比如要精确控制 flush 边界、复用已有字节切片、或对接非 io.Writer 接口。这时可手写简易缓冲器，但务必注意三点：
- 必须用
sync.Pool复用底层数组，避免高频分配（尤其缓冲区 > 4KB） - 写入前检查容量，不足时先
write.Syscall落盘再重置缓冲起始位置，不能简单append导致越界 - 错误处理必须透传：
bufio.Writer的Write方法返回io.ErrShortWrite或底层错误，自研缓冲器也得保持语义一致 - 别为了“更高效”而跳过
bufio——它的实现已高度优化，且经多年生产验证；除非pprof明确指出它是瓶颈，否则纯属过早优化
缓冲机制本身不难，难的是判断哪一层该缓冲、缓冲多大、以及什么时候必须打破缓冲保证可靠性。这些决策点，往往比写几行 bufio 代码更值得花时间对齐业务 SLA。
