os.readfile会直接oom，因它将整个文件一次性加载进内存，无缓冲、不流式、无控制；1gb文件≈1gb堆内存，gc瞬间报警，服务卡死。
为什么 os.ReadFile 会直接 OOM
它把整个文件一次性读进内存，没缓冲、不流式、无控制。1GB 文件 ≈ 1GB 堆内存占用，GC 立刻报警，服务响应卡死。
真正该用的不是“怎么读得更快”，而是“怎么别全读进来”。
- 小文件（os.ReadFile 没问题，简洁安全
- 大文件（> 10MB）：必须用
os.Open+bufio.Reader或bufio.Scanner - 超大文件（> 500MB）：优先考虑
mmap（如github.com/edsrzf/mmap-go），或直接走http.ServeContent零拷贝路径
bufio.Scanner 逐行读时，Buffer 设置不对会 panic
Scanner 默认缓冲区只有 64KB，遇到超长行（比如单行几 MB 的日志或 JSON）直接崩溃：scanner: too long line。
这不是 bug，是设计上的安全限制——但你得主动调。
- 调用
scanner.Buffer(nil, maxLineSize)显式设上限，比如64 * 1024 * 1024（64MB） - 别传
nil当 buffer 底层，否则 runtime 会按需分配，仍可能逃逸到堆 - 若只需提取某字段而非整行，改用
bufio.NewReader+ReadBytes('\n')，更可控
http.ServeContent 走不了零拷贝的三个硬条件
它本该让内核直接 sendfile，结果却 fallback 到 32KB 用户态循环拷贝，CPU 和延迟双双拉高——往往就差这三步。
- 必须传原始
*os.File，不能包bufio.NewReader、io.LimitReader以外的任何 wrapper（io.MultiReader、自定义 reader 都不行） - 必须调
f.Stat()获取ModTime，塞给http.ServeContent第四个参数；手写时间或用time.Now()会导致缓存失效 -
Content-Disposition头必须带filename=，且中文要用mime.QEncoding.Encode("utf-8", "中文名.pdf")写进filename*=字段，否则浏览器当 inline 渲染
并发读同一个大文件反而更慢
4 个 goroutine 各读 1/4？在机械盘或普通 SATA SSD 上，磁头疯狂寻道，总耗时翻倍。这不是 Go 的问题，是 I/O 物理瓶颈。
真要并发，得换思路：按设备分组，而不是按文件切块。
- 先用
os.ReadDir扫出所有目标路径，再按挂载点（statfs或 /proc/mounts）分组 - 同物理盘的路径，只起 1–2 个 goroutine 串行读；不同盘才并行
- 对单个超大文件本身，别拆 goroutine 并发读 ——
os.File.ReadAt虽支持偏移，但随机读在 HDD 上代价极高
缓冲区大小、文件句柄生命周期、底层 FS 是否支持 sendfile，这些细节不显眼，但决定是稳住 P99 还是半夜被告警叫醒。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
