os.ReadFile读大文件必崩，因其内部调用io.ReadAll强制一次性分配整块内存容纳全部内容，1.2GB文件在低内存环境直接触发runtime: out of memory panic；正确做法是采用可控流式处理，如os.Open配合bufio.Scanner或固定缓冲区分块读取。
os.ReadFile 读大文件为什么必崩
它内部调用 io.ReadAll，强制一次性分配整块内存容纳全部内容。1.2GB 文件在容器或低内存环境里，Go 运行时直接 panic: runtime: out of memory。这不是 GC 慢，是设计上就不该这么用——你真正需要的从来不是“全加载”，而是“可控流式”。
bufio.Scanner 按行读取适合什么场景
适合日志、CSV、JSON Lines 等文本类大文件，语义清晰且自动处理换行边界。但要注意：
- 默认缓冲区上限 64KB，超长行（如含 base64 的日志）会触发
bufio.Scanner: token too long错误 - 必须显式调用
scanner.Buffer(make([]byte, 64*1024), 10*1024*1024)扩容，第二个参数是最大 token 长度 - 用
scanner.Text()而非scanner.Bytes()，避免底层数组被长期引用 - 不要在循环中累积
append(lines, line)，否则内存仍会持续上涨
手动分块读取时 buffer 大小怎么设
块大小不是越大越好，也不是越小越稳，得看 IO 类型和硬件：
- 本地 SSD：推荐
1MB–4MB（即make([]byte, 1024*1024)） - NFS 或 USB 3.0 盘：选
32KB–256KB，太大反而卡住 - 纯顺序读写场景下，
bufio.Reader基本没用——它的预读缓冲不控制块边界，还可能因Peek/UnreadByte导致数据错位 - 真正要的是
io.LimitReader(r, n)+io.CopyBuffer(dst, src, buf)组合，前者切块不移动 offset，后者搬运时复用你传入的大 buffer
并发读取大文件反而更慢？关键在哪
不是并发本身错，而是没对齐物理层限制：
立即学习“go语言免费学习笔记（深入）”；
- 单个文件多 goroutine
ReadAt分段读，在机械盘或普通 SSD 上大概率比串行还慢——磁盘寻道开销远大于 CPU 计算 - 若真要并行，必须满足：文件可随机访问 + 块边界对齐（如 4KB 对齐）+ 每个 goroutine 独占
*os.File句柄 - 写入端更要小心：同一目标文件不能多 goroutine 并发
Write，必须加sync.Mutex或走 channel 串行化 - channel 缓冲区别设太大，
make(chan []byte, 16)是较安全的起点；发送前必须copy数据，否则所有 worker 共享同一底层数组
