应优先使用 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 栈。
立即学习“go语言免费学习笔记（深入）”；
- 必须设置读写 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，日志永远差最后几行。
