os.readfile读大文件必然oom，因其内部调用io.readall一次性分配整块内存，超100mb就应改用os.open+固定缓冲区分块流式处理。
直接用 os.ReadFile 读大文件，基本等于主动申请被系统 kill——它不判断文件大小，只管把整块内容塞进内存。真实场景里，只要文件超 100MB，就该默认切换到流式处理。
为什么 os.ReadFile 必须避开
它内部调用 io.ReadAll，强制一次性分配足够容纳整个文件的 []byte。哪怕你只是想 grep 几行日志，Go 也会先 malloc 出 2GB 内存，再等 GC 慢慢反应。常见现象包括：
- 进程 RSS 内存飙升后突然消失，dmesg 显示 “Out of memory: Kill process”
-
pprof中heap_alloc曲线垂直拉升，gc pause时间变长 - 并发打开 5 个 300MB 文件，goroutine 数才 20，但系统内存已耗尽
替代方案不是“换个函数”，而是明确控制读取节奏：用 os.Open 打开句柄，配固定大小缓冲区分块读，手动管理生命周期。
io.Copy 边读边写却卡在 NFS 上？调缓冲区
io.Copy 默认用 32KB 缓冲，对本地 SSD 足够，但在 NFS、CIFS 或 USB 盘上会因 syscall 频繁和 write timeout 导致吞吐骤降，甚至返回 broken pipe。这不是 bug，是缓冲太小触发了底层协议重试机制。
- 实测将缓冲设为
make([]byte, 1024*1024)（1MB），NFS 写入速度可提升 3–5 倍 - 必须用
io.CopyBuffer(dst, src, buf)，不能依赖默认行为 - 若 dst 是 HTTP 响应体或管道，建议加
time.AfterFunc监控单次Write超时，防上游僵死
bufio.Scanner 处理日志时内存悄悄涨满
它默认允许单行最大 64KB，但遇到超长行（比如嵌套 JSON、base64 blob）会自动扩容 buffer，且不报错——这是生产环境最隐蔽的 OOM 诱因。你看到的不是 panic，而是服务缓慢、GC 频繁、内存持续上涨。
- 必须显式调用
scanner.Buffer(make([]byte, 4096), 1，限制最小 4KB、上限 1MB - 若业务需处理任意长度行，改用
bufio.NewReader+ReadSlice('\n')，自己处理io.ErrBufferFull - 切忌在
Scan()循环里做append到全局切片、构造结构体或字符串拼接
Excelize 流式写入百万行却导出空文件？漏了 Flush
Excelize/v2 的 StreamWriter 是真流式：数据先写入内存 buffer，超 16MB 自动落盘，最终靠 Flush 统一生成 XML。但新手常犯的错误是写完循环就结束，没调 sw.Flush()。
- 不调
Flush→ 文件头缺失、sheet.xml 损坏、Excel 打开报“发现不可读内容” -
SetRow只接受严格递增的rowID，跳行或倒序会 panic - 写入完成后必须先
sw.Flush()，再f.Close()，且两者错误都要检查
流式处理真正的复杂点不在代码量，而在资源边界意识：每个 os.File 要 close，每个 bufio.Writer 要 flush，每个 StreamWriter 要 flush，缺一不可——它们不是可选步骤，是协议的一部分。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
