应使用 bufio.reader/writer 批量读写以减少系统调用，优先 mmap 处理大文件随机访问，网络 i/o 需设读超时，复用缓冲区并控制大小，避免内存逃逸与 oom。
用 bufio 包批量读写，别直接调 os.Read 或 os.Write
小块频繁 I/O 是 Golang 程序性能杀手。直接对文件或网络连接调 os.Read 每次都触发系统调用，开销大且无法利用内核页缓存优势。bufio.Reader 和 bufio.Writer 通过缓冲层合并多次操作，显著减少 syscall 次数。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 文件读取：用
bufio.NewReader(file)替代file.Read()；逐行读用scanner := bufio.NewScanner(file)，比手动ReadString('\n')更安全高效 - 网络写入：HTTP handler 中返回 JSON 时，用
json.NewEncoder(bufio.NewWriter(w)).Encode(v)，而非json.Marshal+w.Write—— 后者多一次内存拷贝，且未缓冲 - 缓冲区大小要按场景调：默认 4KB 够通用，但处理日志聚合或大报文时，可设为 64KB（
bufio.NewReaderSize(f, 64*1024)），避免频繁 flush
文件 I/O 优先用 mmap（syscall.Mmap）而非 os.ReadFile
当需随机访问大文件（如 GB 级索引、日志切片、数据库快照），os.ReadFile 会把整个文件加载进 Go 堆，引发 GC 压力和内存暴涨。mmap 让内核按需将文件页映射进进程虚拟地址空间，真正“按需加载”。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 仅适用于只读或固定长度追加场景；写入需配合
msync和保护策略，否则易丢数据 - Go 标准库不直接暴露
mmap，需用golang.org/x/sys/unix.Mmap（Linux/macOS）或syscall.Mmap（Windows） - 注意：mmap 地址不可直接传给
unsafe.String长期持有——文件被 truncate 或 unmap 后指针失效；应封装为带生命周期管理的 struct
网络 I/O 避免阻塞式 conn.Read，改用 net.Conn.SetReadDeadline + 循环读
无超时的 conn.Read 在连接卡顿或对方不发 FIN 时会永久挂起 goroutine，堆积后耗尽内存。单纯用 context.WithTimeout 无法中断底层 syscall，必须靠 deadline 驱动。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 每次读前调
conn.SetReadDeadline(time.Now().Add(5 * time.Second))；超时返回net.ErrDeadlineExceeded，可重试或关闭连接 - 不要在循环里反复 new
bufio.Reader——它内部 buffer 可复用；更不要每次读都make([]byte, N)，应预分配并复用[]byteslice - 高并发下，考虑用
golang.org/x/net/netutil.LimitListener控制连接数，防突发流量打垮 accept 队列
用 io.CopyBuffer 替代 io.Copy 控制内存占用
io.Copy 内部用 32KB 默认 buffer，看似合理，但在内存受限环境（如容器 128MB 限制）或代理类服务中，大量并发 copy 会瞬间吃光可用堆内存。而 io.CopyBuffer 允许你显式指定 buffer 大小并复用。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 代理 HTTP 请求时：用
io.CopyBuffer(dst, src, make([]byte, 8*1024))，8KB 足够平衡吞吐与内存 - buffer 必须是局部变量或池化对象；若从
sync.Pool获取，记得pool.Put(buf)归还，否则逃逸到堆 - 注意：buffer 太小（如 512B）会导致 syscall 过于频繁；太大（如 1MB）则单连接占用过高，需按 QPS × 并发连接数 × buffer 大小预估总内存
真正影响 I/O 性能的往往不是算法，而是缓冲策略、系统调用频率和内存生命周期管理。这些点容易在压测初期被忽略，直到 QPS 上不去、GC 频繁或 OOM 才暴露——动手前先看 strace 或 go tool trace 里的 syscall 占比。
