高频文件写入性能差主因是缓冲配置不当、flush调用错误或并发写句柄错误；bufio.writer需显式flush才落盘，defer close不触发刷盘，且flush后须检查错误，高并发应避免共享writer而改用chan或独立文件句柄。
高频文件写入性能差，八成是因为缓冲没配对、Flush 没调对、或并发写错句柄——不是代码不“Go”，是没踩中系统调用节奏。
bufio.Writer 必须显式 Flush 才算真正落盘
写入后文件为空或缺最后几条？大概率是漏了 wr.Flush()。它不自动刷盘，defer f.Close() 也不隐式触发——Close() 只关 fd，缓冲区数据还在内存里。
- 错误必须在
Flush()后检查：file.Write()几乎总返回nil，真出问题（磁盘满、权限不足）只在Flush()时暴露 -
defer wr.Flush()很危险：函数中途return或panic就跳过，最后一块数据直接丢 - 长周期服务（如日志 daemon）不能只靠结尾一次
Flush()，得配合定时或批量策略
缓冲区大小不是默认 4KB 就行
默认 4096 字节在高频小写入（如每条日志 ~100B）下，每 40 条就刷一次，毫无意义；设太大又拖延迟、涨内存、崩溃时丢数据多。
- 日志追加写（每行 ~100B）：
64 * 1024（64KB）较稳 - 批量导出 CSV/JSON（单次写 >1KB）：
256 * 1024～1024 * 1024（256KB–1MB） - 内存受限环境：
8 * 1024（8KB），避免 GC 压力突增 - 设置方式：
w := bufio.NewWriterSize(file, 64*1024)
高并发写同一文件别共享 writer
bufio.Writer 不是 goroutine 安全的，多个 goroutine 直接共用会 panic；加 sync.Mutex 锁 Write 又容易成瓶颈，且无法解决内核偏移锁竞争问题。
- 推荐方案：用
chan string（带缓冲，如make(chan string, 1000)）做生产者-消费者模型，单一 goroutine 持有bufio.Writer消费并刷盘 - 替代方案：每个 goroutine 独立打开文件（带
os.O_APPEND），各自持有bufio.Writer，避免锁和竞争 - 若复用
bufio.Writer实例，必须用sync.Pool+wr.Reset(f)重绑定文件，不能跨 goroutine 共享未 reset 的实例
Batch 提交要分离“写入”和“刷盘”动作
想压的是单位时间内的系统调用次数，不是函数生命周期内调用次数。defer wr.Flush() 和 defer f.Close() 都只执行一次，完全无效。
- 按时间间隔刷：
time.Ticker启一个 goroutine 定时wr.Flush()，适合日志、监控指标等容忍几百毫秒延迟的场景 - 按数据量刷：自己维护计数器，每次
wr.WriteString()后累加长度，达到阈值（如 1MB）就Flush()，适合吞吐敏感型导出 - 注意：
Flush()是阻塞调用，磁盘慢会导致 ticker 积压，建议加超时或非阻塞检测
最常被忽略的点是：Flush 不只是“让数据落盘”，更是你控制延迟、内存占用、崩溃丢失量的唯一杠杆。设错缓冲、乱用 defer、并发误共享，三者任一都会让优化归零。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
