Go I/O性能瓶颈主因是小块频繁调用和内存乱分配；应使用bufio缓存、sync.Pool复用缓冲区、流式分块读写、合理控制并发度并预分配空间。
Go 程序的 I/O 性能瓶颈，八成出在“小块频繁调用”和“内存乱分配”上——不是硬盘或网卡慢，而是你每写一行日志就 Write 一次，每次读一个包就 Read 一次，还顺手 new 了十次 []byte。优化不是换库，是让每次系统调用干更多活、让每次内存分配更可控。
用 bufio 包装文件和网络连接，别裸调 os.File.Read
裸调 os.File.Read 或 conn.Read 每次都触发 syscall，开销远高于内存拷贝。而 bufio.Reader 和 bufio.Writer 在用户态缓存数据，把 N 次小读写聚合成 1–2 次大 I/O。
- 默认缓冲区（4KB）对日志、配置文件够用，但对大吞吐场景常偏小：用
bufio.NewReaderSize(f, 64*1024)显式设为 64KB 更稳 -
bufio.Scanner适合按行处理（如解析日志），但注意它内部会自动扩容，若行长不可控，改用reader.ReadString('\n')+strings.TrimSpace更可控 - 写入后必须调用
writer.Flush()，否则数据可能滞留在缓冲区不落盘；HTTP 响应体等流式写入场景，可配合http.ResponseWriter的Flusher接口做实时推送 - 别在循环里反复
new bufio.Reader：复用一个实例，或从sync.Pool获取
大文件别 os.ReadFile，分块读 + io.CopyBuffer 更安全
os.ReadFile 简洁，但会把整个文件加载进内存——1GB 文件直接 OOM。真实场景该流式处理，边读边转、边读边传。
- 用
os.Open打开文件，再套bufio.NewReader或直接用io.CopyBuffer(dst, src, make([]byte, 64*1024))，显式复用缓冲区避免反复分配 - 复制大文件时，
io.Copy内部已优化块大小，但若目标支持WriteAt（如本地磁盘），可结合file.Seek+ 分片并发读，注意 SSD 上并发 8–16 路较优，HDD 则 2–4 路更稳 - 预分配目标文件空间：写前调用
output.Truncate(size)，减少文件系统元数据更新和碎片 - 追加写日志？打开时加
os.O_APPEND标志，保证原子性，避免多个 goroutine 写同一文件时覆盖
高频 I/O 场景下，sync.Pool 复用缓冲区比 make([]byte, n) 省 30%+ GC 压力
HTTP 服务每秒处理上千请求，每个请求都 make([]byte, 4096)，GC 会频繁扫描这些短期对象。用 sync.Pool 缓存常见尺寸的切片，效果立竿见影。
立即学习“go语言免费学习笔记（深入）”；
- 定义全局池：
var bufPool = sync.Pool{New: func() interface{} { return make([]byte, 0, 32*1024) }} - 使用时：
buf := bufPool.Get().([]byte); buf = buf[:0]; ...; bufPool.Put(buf) - 注意：归还前清空敏感内容（如
buf = buf[:0]），避免跨请求泄露数据 - 别池化大对象（如结构体指针），只池化高频、定长、无状态的
[]byte或bytes.Buffer
并发读写文件时，别盲目开 goroutine，用 worker pool 控制实际并行度
开 100 个 goroutine 同时读文件，磁盘寻道和内核锁反而让吞吐暴跌。I/O 并发的关键不是数量，是“错开等待”，并避开硬件瓶颈。
-
机械硬盘：并发 2–4 个 worker 即可；NVMe SSD 可试到 16–32，但需实测
iostat -x 1看 %util 是否持续 >90% - 用带缓冲 channel 当信号量：
sem := make(chan struct{}, 8)，每个 goroutine 先sem 再操作，完成后 - 同一文件多 goroutine 读是安全的（
os.File内部有syscall.Seek隔离），但写必须串行：要么加sync.Mutex，要么用单个 writer goroutine 消费 channel 输入 - 网络 I/O 并发同理：别为每个 HTTP 请求启 goroutine 就完事，用
errgroup.Group+ctx.WithTimeout统一控制生命周期和错误传播
最常被忽略的点：缓冲区大小不是越大越好，64KB 是多数场景的甜点，再大容易浪费内存且不提升吞吐；还有就是 Flush() 容易忘，一忘就丢数据——尤其在程序异常退出时，记得用 defer writer.Flush() 或在关键路径显式调用。
