热路径I/O必须合理使用bufio.Reader/Writer：缓冲区大小需按场景定制（如HTTP用8KB、日志按行长+128B、大文件用64–128KB），Flush须显式调用且注意panic/os.Exit差异，多goroutine写需channel串行化，纯流复制或强一致性场景应绕过bufio。
热路径上频繁 I/O 必须用 bufio.Reader 和 bufio.Writer，但不能只套一层就完事——缓冲区大小、Flush 时机、并发模型这三点没对齐，性能反而更差。
缓冲区大小设多少才不拖慢热路径
默认 bufio.DefaultBufferSize（4096 字节）在多数 HTTP handler 或日志打点场景下会频繁触发 flush，尤其当单次写入远小于 4KB（比如每条日志平均 200B）时，实际系统调用次数可能只降了 2–3 倍，远低于理论值。
实操建议：
- HTTP 响应或 JSON API 输出：按平均响应体设，如
bufio.NewWriterSize(w, 8192)（8KB），避免因小响应反复刷出 - 结构化日志（每行固定字段）：预估单行最大长度 + 128 字节，比如最长 1.2KB，就用
bufio.NewWriterSize(w, 1331)，减少内部切片扩容 - 大块二进制流（如文件分片上传/下载）：直接上
64 * 1024或128 * 1024，strace -e trace=write可验证 syscalls.read/write 次数是否明显下降 - 别设 >1MB 缓冲区：Go runtime 会把它分配到堆上，GC 扫描压力上升，延迟抖动变大
Flush 不手动调，热路径输出就“消失”
常见错误现象：服务跑着看起来正常，但日志文件空、监控指标没上报、下游收不到完整响应体——本质是 bufio.Writer 缓冲区没满，又没显式 Flush()，程序退出或 panic 时缓冲区被直接丢弃。
立即学习“go语言免费学习笔记（深入）”；
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
关键约束：
-
net/http的ResponseWriter不是bufio.Writer，不能直接传给bufio.NewWriter；若需缓冲响应，得自己包装http.ResponseWriter并确保在WriteHeader后、handler 返回前调wr.Flush() - panic 场景下
defer wr.Flush()仍有效，但os.Exit()会跳过 defer，必须在 exit 前显式 flush - 如果要求强一致性（如事务日志），
Flush()后还得补f.Sync()，否则数据可能卡在内核页缓存里
多个 goroutine 写同一个文件？别共享 bufio.Writer
并发写入同一文件时，直接把一个 *bufio.Writer 丢给多个 goroutine，会出现数据错乱、部分丢失、甚至 panic：它的内部缓冲区、写偏移、错误状态全非并发安全。
更稳的解法：
- 用 channel + 单 writer goroutine：所有写请求发到
chan []byte，消费者用bufio.Writer批量写入；channel 缓冲设为 1000–10000，防内存暴涨 - 写协程退出前，必须
close(ch)并在 for 循环后调wr.Flush()，否则最后一段内容滞留 - 别用
log.SetOutput直接设成bufio.Writer——log包不保证调Flush()，日志会丢
什么时候该绕过 bufio 直接 syscall
缓冲不是银弹。以下情况用原生 os.File.Write 或 io.Copy 更合适：
- 纯流复制（如文件中转、代理转发）：用
io.Copy(dst, src)，它内部已用 32KB 零拷贝缓冲，比套两层bufio更快且无锁竞争 - 关键落盘操作（如 WAL 日志）：每条记录必须立即持久化，禁用缓冲，直接
f.Write(p); f.Sync() - 高频超小写入（如每毫秒写 1 字节心跳）：缓冲区永远填不满，反而增加内存和判断开销；不如攒一批再写，或换用内存映射 + 原子写
真正难的是判断「热」在哪——先用 strace -p $PID -e trace=write,read 看系统调用频次，再决定要不要缓冲、缓冲多大、谁来 flush。没测就调参，大概率白忙。
