应优先使用 bufio.Reader/Writer 减少系统调用，注意 Flush() 和避免混用；批量读取用 io.ReadFull/io.CopyN；大文件顺序写可选 O_DIRECT（需对齐）；网络 I/O 必设 ReadDeadline 防阻塞。

用 bufio.Reader / bufio.Writer 替代原生 os.File 读写

直接调用 file.Read() 或 file.Write() 会触发频繁系统调用，每次读写都可能陷入内核态。而 bufio.Reader 和 bufio.Writer 在用户态维护缓冲区，大幅减少系统调用次数。

• 默认缓冲区大小为 4096 字节，对大多数场景够用；若处理大块日志或二进制流，可显式指定更大缓冲（如 bufio.NewReaderSize(file, 64*1024)）
• 注意：bufio.Writer 必须显式调用 Flush()，否则最后一批数据可能滞留在缓冲区不落盘
• 不要在同一个 *os.File 上混用原生方法和 bufio —— 缓冲区状态不同步会导致数据错位或丢失

批量读取时优先用 io.ReadFull 或 io.CopyN，而非循环 Read

循环调用 Read() 容易写出「每次只读几个字节」的低效逻辑，尤其在网络或管道场景下，小包读取开销显著放大。

• io.ReadFull(r, buf) 保证填满整个 buf，适合固定结构解析（如头部 8 字节长度字段 + 后续 N 字节载荷）
• io.CopyN(dst, src, n) 比手动循环更简洁安全，底层已做最优分片，避免边界错误
• 避免这种写法：

  for len(buf) > 0 { n, _ := r.Read(buf); buf = buf[n:] }

  —— 它无法处理 EOF 提前到达、部分读等情况，且无性能优势

文件 I/O 避免阻塞式 os.OpenFile + 同步写，改用 O_DIRECT 或异步预写（需权衡）

普通磁盘写入默认经过页缓存，看似快，但高并发写入时可能引发 writeback 峰值抖动；而 O_DIRECT 绕过缓存直写设备，适合大文件顺序写，但要求对齐（buffer 地址 & size 需按 512B 对齐）。

• Linux 下启用：

  f, err := os.OpenFile("log.bin", os.O_WRONLY|os.O_CREATE|syscall.O_DIRECT, 0644)

• 更通用的优化是结合 sync.Pool 复用大 buffer，并用 file.WriteAt 实现无锁分段写（适用于多 goroutine 写同一文件不同区域）
• O_DIRECT 不是银弹：小写入会变慢，SSD 友好性差，且 Go 标准库未封装对齐逻辑，需自行用 syscall.Mmap 或 Cgo 配合

网络 I/O 别卡在 conn.Read，用 net.Conn.SetReadDeadline + select 控制超时

I/O 密集型服务最怕某个连接长期阻塞，拖垮整个 goroutine 调度。单纯依赖 Read 阻塞，等于把控制权完全交给 TCP 栈。

• 必须设置读写 deadline：

  conn.SetReadDeadline(time.Now().Add(5 * time.Second))

• 配合 select 实现非阻塞等待：

  select {
  case <-done:
      return
  default:
      n, err := conn.Read(buf)
      if err != nil {
          // 处理 timeout/io.EOF/other
      }
  }

• 不要依赖 SetReadBuffer 提升性能 —— 它只影响内核 socket 接收队列大小，对应用层吞吐无实质帮助

缓冲区对齐、deadline 控制、缓冲复用，这些点不在文档首页，但线上压测一跑就暴露。没设 deadline 的连接，撑不过一次网络抖动；忘了 Flush() 的 writer，日志永远差最后几行。