os.readfile 会 oom 是因将整个大文件一次性加载进内存，超出 go 运行时单次分配限制；应改用 io.limitreader + io.copy 流式分块处理，推荐块大小 32kb–1mb。
为什么直接用 os.ReadFile 会 OOM？
读取几个 GB 的文件时，os.ReadFile 会把整个文件加载进内存，触发 GC 压力甚至直接 panic：runtime: out of memory。这不是磁盘空间问题，是 Go 运行时对单次分配的限制（尤其在 32 位环境或低内存容器中）。流式处理的核心不是“快”，而是“可控”——控制每次只拿一小块，处理完就丢。
用 io.CopyN + io.MultiReader 实现精确分块
别一上来就写 for 循环读 buf，容易漏边界、错偏移。更稳的方式是组合标准库：用 io.LimitReader 切出固定大小块，再用 io.Copy 写入目标（如 os.File 或网络连接）。关键点：
-
io.LimitReader(r, n)返回一个只读前n字节的新io.Reader，不移动原 reader 的 offset - 若需跳过开头 N 字节，用
io.CopyN(io.Discard, r, n)，比Seek更通用（适配 pipe、http.Response.Body 等不可 seek 的 reader） - 分块大小建议设为
32 * 1024（32KB）到1024 * 1024（1MB）之间；太小增加 syscall 开销，太大削弱流控效果
bufio.Reader 在大文件流式读中其实帮不上忙
很多人第一反应是包一层 bufio.Reader 提升性能，但它对纯顺序大文件读写收益极低，反而可能掩盖问题：
-
bufio.Reader的缓冲区（默认 4KB）只是预读，不改变整体内存占用模型 - 若后续逻辑需要按行解析（
ReadString('\n')），它才有意义；但分块写入场景通常不需要行边界 - 误用
Peek/UnreadByte可能导致数据错位，尤其在 chunk 边界处
直接用底层 os.File 或 bytes.Reader 配合 io.LimitReader 更透明、更易调试。
写入端必须用 os.O_CREATE | os.O_WRONLY | os.O_APPEND 吗？
不一定。分块写入时，打开模式取决于你是否需要原子性或并发安全：
- 单 goroutine 顺序写：用
os.O_CREATE | os.O_WRONLY | os.O_TRUNC，先清空再写，避免残留旧数据 - 多 goroutine 并发写不同偏移：必须用
os.O_CREATE | os.O_WRONLY+WriteAt，且确保每个 chunk 的offset不重叠 -
os.O_APPEND看似省事，但会强制每次 write 系统调用前 seek 到 EOF，丧失 chunk 大小可控性，且无法指定写入位置
真正要注意的是：写入前务必检查 error，尤其是 write: broken pipe 或 no space left on device —— 流式处理中这类错误不会立刻暴露，可能卡在中间某一块后静默失败。
