os.readfile 会 oom 是因一次性加载整个大文件进内存；应改用 io.reader 模型按需读取，配合 bufio.newreader 和 io.copyn 控制块大小，立即处理不缓存，并注意检查 read 返回的 n 和 err 组合。
为什么直接用 os.ReadFile 会 OOM？
大文件（比如 2GB 日志或视频）调用 os.ReadFile 会一次性把全部内容加载进内存，Go 程序很快触发 GC 压力甚至被系统 kill。这不是读取逻辑错了，而是模型错了——你不需要“整个文件”，只需要“按需看一部分”。io.Reader 正是为此存在：它不承诺长度、不预分配内存，只提供「每次最多读 N 字节」的能力。
用 bufio.NewReader + io.CopyN 控制块大小
别自己写循环读 byte 切片，容易丢边界、漏错误。标准库已有成熟组合：
-
bufio.NewReader包装原始*os.File，提升小读取的效率（避免系统调用频繁） -
io.CopyN可精确控制本次读多少字节，返回实际读到数，且自动处理 EOF 和部分读场景 - 每次读完立即处理（如解析 JSON 行、计算哈希、写入另一文件），不缓存整块数据
示例关键片段：
reader := bufio.NewReader(file)
buf := make([]byte, 64*1024) // 64KB 块
for {
n, err := io.CopyN(&myProcessor, reader, int64(len(buf)))
if n > 0 {
// myProcessor 已收到 n 字节，可立刻处理
}
if err == io.EOF || err == io.ErrUnexpectedEOF {
break
}
if err != nil {
return err
}
}
io.LimitReader 在嵌套流中更安全
当你的处理逻辑本身也接受 io.Reader（比如传给 json.NewDecoder 或 gzip.NewReader），直接切原始 reader 容易越界或状态错乱。这时用 io.LimitReader 包一层，语义清晰又防误用：
- 它不消耗数据，只是“在内部 reader 上加个字节上限”
- 适合分块解压、分块解析 JSON 数组流（每个块独立 decode）
- 注意：它不保证恰好读满上限，遇到 EOF 就停，所以要检查返回的
n
比如读一个 gzip 分块：
limited := io.LimitReader(reader, 1024*1024) // 限制 1MB
gz, err := gzip.NewReader(limited)
if err != nil {
// 注意：err 可能是 io.ErrUnexpectedEOF，表示没读满就断了
}
defer gz.Close()
别忽略 Read 返回的 n 和 err 组合
这是流式读取最容易翻车的地方。常见错误模式：
- 只检查
err != nil就退出，但Read在 EOF 时可能先返回n > 0, err == nil，再下一次才n == 0, err == io.EOF - 假设
Read(buf)一定填满buf，其实只要读到一点就返回（尤其网络或管道 reader） - 用
len(buf)当作本次有效数据长度，而没用返回的n
正确姿势永远是：
n, err := reader.Read(buf)
if n > 0 {
process(buf[:n]) // 仅处理前 n 字节
}
if err == io.EOF {
break // 真正结束
}
if err != nil && err != io.EOF {
return err
}
流式读取的边界比想象中毛糙，n 才是唯一可信的数据长度来源。
