直接用os.readfile读大文件必然oom，因其无缓冲、无分块、全量加载，超200mb易触发runtime: out of memory；应改用os.open+bufio.newreader或io.limitreader流式分块处理，缓冲区建议64kb–1mb，显式控制生命周期。
直接用 os.ReadFile 读大文件基本等于主动触发 OOM，它不区分文件大小，一律全量加载进内存；真正高效的做法是放弃“读完再处理”的思维，改用流式 + 缓冲 + 显式生命周期控制。
为什么 os.ReadFile 在大文件场景下必须禁用
它内部无缓冲、无分块、无进度感知，对几百 MB 以上的文件会瞬间吃光可用内存，且无法中断或限速。错误日志里出现 runtime: out of memory 或长时间卡在 GC 扫描，八成是它在后台默默分配了一个超大 []byte。
- 即使文件只有 200MB，
os.ReadFile也会尝试分配一块连续内存——在内存碎片化严重的进程里极易失败 - 它不返回
*os.File，你无法复用句柄、无法Seek、无法并发控制读取位置 - 没有错误恢复能力：读到一半磁盘断开，整个操作就彻底失败，没法从断点续读
用 bufio.NewReader 做可控分块读取
核心是把“读文件”拆成“打开 → 预设缓冲 → 循环读 → 即时处理 → 丢弃引用”五步，内存占用恒定在缓冲区大小级别。
- 缓冲区大小选 64KB（
1 ）较均衡：太小（如 4KB）导致系统调用频繁；太大（如 1MB）对普通 SSD 并无明显收益，反而延迟错误暴露 - 避免用
ReadString('\n')处理可能含超长行的日志——单行若达 500MB，缓冲区会被撑爆；改用ReadBytes('\n')或手动Read+ 扫描 - 每次读完立即处理
buf[:n]，切忌保存buf本身；若需持久化某段内容，用append([]byte(nil), buf[start:end]...)显式拷贝
逐行处理优先用 bufio.Scanner，但必须调大缓冲
bufio.Scanner 默认单行上限 64KB，遇到未切割的巨型 JSON 或压缩包 Base64 字符串会直接 panic 报 scanner: token too long。
- 务必在初始化后调
scanner.Buffer(make([]byte, 64*1024), 1：第一个参数是初始缓冲，第二个是最大容量（建议设为 1MB） - 用
scanner.Text()而非scanner.Bytes()——前者返回新分配字符串，后者共享底层 reader 缓冲，一不留神就让整块缓冲无法被 GC - 若只是校验、计数、提取关键词，别把整行转成
string再strings.Contains；直接在[]byte上用bytes.Contains，零额外分配
超大只读文件（GB 级）可考虑 mmap
适用于日志归档分析、数据库快照解析等**随机访问多、顺序读少、绝不修改**的场景；它绕过内核页缓存，由 OS 按需加载物理页，访问延迟低。
- 用
github.com/edsrzf/mmap-go，不是标准库，需额外引入；Windows 支持弱，Linux 生产环境更稳 - 映射后得到的是
[]byte，可直接用unsafe.Slice或binary.Read解析二进制结构，避免反复Read系统调用 - 风险点：文件被外部截断会导致
SIGBUS；写入需显式msync；映射区域过大可能耗尽虚拟地址空间（尤其 32 位进程）
最易被忽略的一点：无论用哪种方式，只要开了 *os.File，就必须确保 Close() 被调用——文件描述符泄漏比内存泄漏更隐蔽，且不会触发 GC 自动清理。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
