默认bufio.writer在高负载下易出问题：4kb缓冲区高频写入易满致flush频繁、多goroutine共享会数据错乱；需自行实现定量+定时双触发刷新，避免滞留或过刷；严禁并发写同一writer，应采用单协程队列、分片文件或sync.pool复用；file.sync()性能极低，仅在强一致性场景按量/定时使用。
为什么默认 bufio.Writer 在高负载下容易出问题
默认 4KB 缓冲区在高频写入时几乎每次都会满，Flush() 被频繁触发，系统调用次数不降反升；更隐蔽的问题是：多个 goroutine 共享一个 bufio.Writer 会直接导致数据错乱，而错误往往只在压测后期才暴露。
定量 + 定时双触发刷新必须自己实现
bufio.Writer 本身不提供自动刷新机制，依赖业务层控制。单纯用 time.Ticker 定时刷，会在低流量时滞留数据（比如最后一条日志卡住 300ms），高流量时又因缓冲区溢出被迫提前刷，反而增加调用频次。
- 每次写入后检查
w.Available() （即填充 ≥80%）就立即 <code>Flush() - 用全局
*time.Timer配合timer.Reset(300 * time.Millisecond)实现兜底超时 - 不能在函数内 new Timer，否则每次调用都新建，timer.Stop() 也无从谈起
-
Flush()后必须重置 timer，否则超时逻辑失效
高并发写同一文件时别碰 bufio.Writer 共享
多个 goroutine 直接往同一个 bufio.Writer 写，即使加了 mutex，也会因内部状态（如 buf、n、err）被并发修改而 panic 或丢数据。这不是 race condition，而是结构体非线程安全的底层事实。
- 方案一：单写协程 + channel 队列，所有写请求发消息过去，由它顺序处理并
Flush() - 方案二：按业务维度分片，比如
log_20260614_user_123.log，每个文件配独立bufio.Writer - 方案三：用
sync.Pool复用bufio.Writer，但每次写前必须调w.Reset(file)关联新文件句柄
file.Sync() 是吞吐量杀手，除非你真需要 crash-safe
每调一次 file.Sync()，SSD 上平均耗时 >1ms，机械盘可能到 10ms —— 这直接抵消掉所有缓冲收益。很多线上服务把 Sync() 当“保险丝”用，结果 QPS 跌一半。
- 普通日志或中间状态，只做
Flush()即可（数据进内核页缓存） - 若需断电不丢，改用 WAL 日志或嵌入式数据库（如 bbolt），而不是靠 Sync 硬扛
- 真要 Sync，建议按量触发：每写满 1MB 或每 5 秒一次，用
atomic.AddUint64(&bytesWritten, int64(n))计数
真正难的不是写对代码，而是判断哪条路径该走：小批量实时写、大批量离线导出、还是高并发追加日志——每种场景下缓冲区大小、刷新时机、是否 Sync 的取舍点都不同，且无法靠一套配置通吃。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
