os.readfile一读大文件就oom，因其内部硬编码调用io.readall，不查文件大小、不设上限，直接malloc一块和文件等大的[]byte；500mb文件→至少500mb连续堆内存→触发runtime: out of memory或被oom killer杀掉。
os.ReadFile 为什么一读大文件就 OOM
它内部硬编码调用 io.ReadAll，不查文件大小、不设上限，直接 malloc 一块和文件等大的 []byte。500MB 文件 → 至少 500MB 连续堆内存 → 很可能触发 runtime: out of memory 或被系统 OOM Killer 杀掉。
常见现象包括：pprof 中 heap_alloc 垂直拉升、dmesg 出现 Out of memory: Kill process、并发打开几个 300MB 文件后 RSS 内存瞬间飙到数 GB。
- 别指望 GC 救场：GC 来不及回收，分配压力已压垮调度器
- 不是“偶尔出问题”，是设计上就拒绝大文件——
os.ReadFile的语义就是“整块载入”，不是流式接口 - 哪怕你只 grep 一行，它也照单全收整个文件
bufio.Scanner 按行读取必须显式限缓冲区
bufio.Scanner 看似安全，但默认单行上限 64KB，遇到嵌套 JSON、base64 blob 或日志中意外的超长字段时，会静默扩容 buffer，且不 panic —— 内存悄悄涨满，直到 GC 频繁、响应变慢、服务卡死。
必须在 scanner.Scan() 前调用 scanner.Buffer() 显式约束：
- 最小 buffer 建议设为
4096（4KB），防初始化开销过大 - 最大上限建议 ≤
1048576（1MB），再大就该换bufio.NewReader+ReadSlice('\n') - 不设上限 = 放任攻击者用单行 2GB 数据打穿你的内存
io.CopyBuffer 和自定义缓冲区才是可控路径
真正可控的大文件处理，核心是「固定缓冲区 + 显式生命周期管理」。不要依赖默认行为，尤其是 io.Copy 默认 32KB 缓冲在 NFS、CIFS 或 USB 盘上会因 syscall 频繁和 write timeout 导致吞吐骤降甚至 broken pipe。
- 缓冲区大小建议设为
make([]byte, 1024*1024)（1MB）：NFS 场景实测提速 3–5 倍 - 必须用
io.CopyBuffer(dst, src, buf)，不能只写io.Copy(dst, src) - 若
dst是 HTTP 响应体或管道，加time.AfterFunc监控单次Write超时，防上游僵死拖住 goroutine -
buf应复用（如用sync.Pool），否则每轮 new 切片仍会加剧 GC 压力
http.MaxBytesReader 是上传场景不可跳过的闸门
不加 http.MaxBytesReader，r.ParseMultipartForm、json.Unmarshal、甚至 io.ReadAll(r.Body) 全部无上限读取请求体。攻击者发个 2GB POST，你的服务大概率先 OOM 再 panic。
- 必须在任何读取操作前执行：
r.Body = http.MaxBytesReader(w, r.Body, 10<code>MB)，只调用不赋值等于没做 -
r.ContentLength不可靠：HTTP/1.1 分块传输时恒为-1，唯一防线就是MaxBytesReader -
ParseMultipartForm(32<code>MB) 只控内存缓存大小，超出部分落盘到os.TempDir()—— 磁盘可能被写满，临时文件还可能残留 - 务必配
http.Server.ReadHeaderTimeout和ReadTimeout（建议分别设为 2s / 5s），从连接层切断慢速攻击
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
