os.ReadFile读大文件必崩，因其内部调用io.ReadAll强制一次性加载全部内容到内存，1.2GB文件在低内存环境直接触发runtime: out of memory panic；正确做法是用io.LimitReader+io.CopyBuffer流式分块处理。
os.ReadFile 读大文件为什么必崩
因为 os.readfile 内部调用 io.readall，强制一次性分配整块内存容纳全部内容。1.2gb 文件在容器或低内存环境里，go 运行时直接 panic：runtime: out of memory。这不是 gc 慢，是设计上就不该这么用——你真正需要的从来不是“全加载”，而是“可控流式”。
分块读写的最简可靠组合
别写 for 循环手动 Read + buf 管理，容易漏 io.EOF 边界、错偏移、误判 io.ErrUnexpectedEOF。标准库已有成熟组合：
-
io.LimitReader(r, n)切出固定大小块，不移动原r的 offset，适合链式处理 -
io.Copy或io.CopyBuffer(dst, src, buf)负责搬运，内部自动分块，不暴露缓冲细节 - 块大小设为
32 * 1024（32KB）到1024 * 1024（1MB）之间：太小 syscall 过多；太大削弱流控，且在 NFS/USB 盘上反而卡住
bufio.Reader 在纯分块场景下基本没用
很多人第一反应是包一层 bufio.Reader，但它对顺序流式读写无实质收益：它的缓冲区（默认 4KB）只是预读，不改变内存占用模型，也不帮你控制块边界。反而可能掩盖问题——比如误用 Peek 或 UnreadByte 导致 chunk 边界数据错位。真要按行解析才值得加；否则直接用 *os.File 或 bytes.Reader 配合 io.LimitReader 更透明、更易调试。
io.CopyBuffer 比 io.Copy 必须显式用
io.Copy 默认用 32KB 缓冲，在本地磁盘尚可，但在 NFS、慢速 USB 盘或高延迟网络代理中会频繁阻塞，吞吐暴跌甚至触发 write timeout。必须显式传入大缓冲：
buf := make([]byte, 1024*1024) // 1MB _, err := io.CopyBuffer(dst, src, buf)
实测 NFS 上提速 3–5 倍；目标是 HTTP 响应体时，也比裸 io.Copy 更稳，尤其客户端网络抖动时。
真正难的不是“怎么分块”，而是块边界与业务逻辑的对齐——比如加密解密流、协议头校验、断点续传偏移记录，这些地方一不留神就丢数据或错位。缓冲区再大，也救不了逻辑层的 offset 管理漏洞。
