os.ReadFile 会因硬编码调用 io.ReadAll 而直接分配与文件等大的内存，导致大文件读取时 OOM；bufio.Scanner 需显式设 buffer 上限防静默扩容；io.CopyBuffer 须指定固定缓冲区并复用；http.MaxBytesReader 必须前置限流；os.File 需及时 Close 防 fd 泄漏。
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 的语义就是“整块载入”，不是流式接口。
bufio.Scanner 必须显式限缓冲区
bufio.Scanner 看似安全，但默认单行上限 64KB，遇到嵌套 JSON、base64 blob 或日志中意外的超长字段时，会静默扩容 buffer，且不 panic —— 内存悄悄涨满，直到 GC 频繁、响应变慢、服务卡死。
立即学习“go语言免费学习笔记（深入）”；
- 必须在
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)，只调用不赋值等于没做。
实际部署中，这个阈值要结合业务定：普通表单可设 10MB，图片上传可放宽到 100MB，但绝不能设为 0 或负数；同时配合 GOMEMLIMIT（如 1.5g）让 GC 提前介入，避免 RSS 暴涨后才被 kill。
最容易被忽略的是：流式处理中，os.File 必须及时 Close()，否则 fd 泄漏会先于内存耗尽导致 too many open files 错误——这往往比 OOM 更早击穿服务。
