os.ReadFile不能用于大文件因会一次性加载全部内容致OOM；应改用流式接口如os.Open+bufio.Scanner或bufio.NewReader；io.Copy在NFS等慢盘上需调大缓冲区；sync.Pool复用小缓冲区反而更慢；务必及时关闭os.File防fd泄漏。
大文件读取时内存暴涨，os.ReadFile 为什么不能用
因为 os.ReadFile 会把整个文件一次性加载进内存。哪怕只是读一个 2GB 的日志，程序瞬间就 OOM——Go 的 GC 压根来不及回收，进程直接被系统 kill。
真实场景里，你通常只需要逐行处理、按块解析、或边读边转码，根本不需要全量驻留。这时候必须换流式接口。
- 用
os.Open+bufio.Scanner处理文本行（注意Scanner.Scan默认 64KB 缓冲，超长行会失败） - 对二进制或超长行，改用
bufio.NewReader+Read或ReadSlice - 避免
ioutil.ReadAll（已弃用）和bytes.Buffer.ReadFrom这类“攒满再吐”的操作
io.Copy 直接转发大文件，但为什么写不进 NFS 或慢盘就卡住
io.Copy 默认使用 32KB 内部缓冲区，看似合理，但在网络文件系统（如 NFS）、USB 设备或高延迟磁盘上，小块写入会导致大量 syscall 和等待，吞吐骤降，甚至因 write timeout 触发 broken pipe 错误。
关键不是换函数，而是调大缓冲区并控制写入节奏：
立即学习“go语言免费学习笔记（深入）”；
- 用
io.CopyBuffer(dst, src, make([]byte, 1 把缓冲设成 1MB（实测在 NFS 上提速 3–5 倍） - 若目标是 HTTP 响应体或管道，且上游不可控，加
time.AfterFunc监控单次Write超时，主动断开防僵死 - 别依赖
os.File.WriteAt做随机写大文件——它在 ext4 上可能触发隐式同步，比顺序写慢一个数量级
分块读写时 io.ReadFull 和 Read 混用导致数据截断
很多人想“精确读 N 字节”，就无脑用 io.ReadFull，但它在 EOF 时直接返回 io.ErrUnexpectedEOF，而实际业务中，最后一块往往不足 N 字节——这不是错误，是正常结束信号。
正确做法取决于你的协议边界是否严格：
- 如果格式要求每块必须满（如加密块、固定头结构），才用
io.ReadFull；否则一律用Read，检查返回的n, err： -
n == 0 && err == io.EOF→ 文件结束 -
n > 0 && err == nil→ 正常读到数据 -
n > 0 && err == io.EOF→ 最后一块，数据有效，可处理
用 sync.Pool 复用缓冲区，但为什么压测反而更慢
复用 []byte 确实能减少 GC 压力，但 sync.Pool 本身有锁和逃逸成本。如果你每次只从池里取 4KB 缓冲，却在 10us 内就用完并归还，那锁竞争和指针跳转开销已经盖过内存节省。
真正有效的复用只在两种情况成立：
- 缓冲区 ≥ 64KB，且单次生命周期 ≥ 几百微秒（比如解压一段 chunk 后再编码）
- 全局池只供少数 goroutine 频繁争抢（如 HTTP server worker），且通过
pool.New预设构造函数避免运行时反射 - 更轻量的替代：用
make([]byte, 0, size)配合cap检查，在循环内复用底层数组，不碰 Pool
流式处理最易被忽略的点，是忘记关闭底层 os.File —— defer f.Close() 在大文件处理函数里写错位置，或者被 return 绕过，fd 泄漏比内存泄漏更快拖垮服务。
