os.readfile读大文件必然oom，因其内部调用io.readall一次性将全部内容加载到内存，如1.2gb日志会瞬间耗尽堆内存并被系统oom killer终止；安全做法是os.open配合bufio.newreader或scanner流式分块读取，内存占用仅与缓冲区大小相关。
为什么直接用 os.ReadFile 读大文件会 OOM
因为 os.ReadFile 必须把整个文件一次性加载进内存，哪怕只是 1.2GB 的日志，Go 进程也会瞬间吃光可用堆内存，被系统 OOM killer 杀掉。这不是 GC 慢的问题，是设计上就不该这么用——你通常只需要分块处理、边读边转、或流式转发。
真正安全的起点永远是 os.Open + io.Reader 组合。它不预分配，只按需拉取，内存占用稳定在缓冲区大小级别（比如 1MB），和文件总大小无关。
bufio.NewReader 分块读取时怎么控制每次读多少字节
关键不是“设置 Reader 缓冲区大小”，而是每次调用 Read 时传入的 []byte 长度决定了单次最大读取量。缓冲区大小（如 bufio.NewReaderSize(file, 64*1024)）只影响底层预读效率，不强制单次读取量。
- 显式控制块大小：用固定长度切片，例如
buf := make([]byte, 4*1024*1024)（4MB），然后n, err := reader.Read(buf) - 最后一块必然不足：当
err == io.EOF且n > 0时，buf[:n]就是有效数据，必须处理 - 别用
ReadFull：它要求必须读满len(buf)，遇到 EOF 直接返回io.ErrUnexpectedEOF，而大文件末尾块不满是常态，不是错误 - 缓冲区大小建议设为 32KB–1MB：太小（如 4KB）导致 syscall 过多；太大（如 64MB）浪费内存且无收益
用 io.CopyBuffer 流式转发时为什么 NFS 或慢盘会卡住
io.Copy 默认内部用 32KB 缓冲，看似合理，但在 NFS、USB 设备、高延迟磁盘上，小块写入会触发大量阻塞 syscall，吞吐暴跌，甚至因 write timeout 导致 broken pipe。
- 必须显式用
io.CopyBuffer(dst, src, make([]byte, 1024*1024))把缓冲提到 1MB（实测 NFS 上提速 3–5 倍） - 目标是 HTTP 响应体时，
io.CopyBuffer(w, file, buf)比裸io.Copy更稳，尤其客户端网络波动时 - 如果上游 reader 不稳定（如网络流、加密解密流），加一层
bufio.NewReader可平滑数据供给节奏，避免下游 writer 频繁等待 - 永远 defer 关闭
*os.File：漏关会导致 fd 耗尽，后续os.Open直接失败
分块读取后如何安全拼接或转发到多个输出目标
常见误区是启一堆 goroutine 并发写同一文件，结果数据错乱或竞态。正确做法取决于目标是否共享：
- 写入多个独立文件（如按哈希分桶）：每个 goroutine 持有专属
*os.File，无需锁，但记得用bufio.NewWriterSize(file, 1包装提升写入效率 - 写入单个文件：必须串行，用 channel 中转 + 单个 writer goroutine，或用
sync.Mutex保护file.Write - 若需校验或断点续传：每块读完立刻计算
sha256.Sum256(buf[:n])，把 hash 和 offset 记录到元数据，别等全读完再算 - 不要自己拼
[]byte：用io.MultiReader组合多个bytes.Reader是安全的，但别用append往一个 slice 狂加——容量失控风险极高
io.Reader 的流式链路（比如 gzip.Reader → aes.Cipher → bufio.Reader），都依赖上游是否及时返回 io.EOF。一旦某层实现错误（如自定义 reader 忘了在数据耗尽时返回 io.EOF），下游就会永远阻塞在 Read 调用上，没有超时，没有提示，只有卡死。
