os.ReadFile 读大文件会卡住，因其一次性将全部内容加载到内存，大文件导致内存分配与拷贝耗时剧增，甚至触发 OOM；不适用于超 10MB 场景，仅适合配置文件、小 JSON 等轻量文本。
为什么 os.ReadFile 读大文件会卡住？
因为它是把整个文件一次性加载进内存，文件越大，分配内存+拷贝时间越长，还可能直接触发 OOM。不是“慢”，是设计上就不适合 >10MB 的场景。
常见错误现象：runtime: out of memory 或 GC 频繁、CPU 占用高但进度不动。
- 适用场景：配置文件、小 JSON、模板文本（
- 不适用场景：日志归档、CSV 导入、视频元数据提取等流式处理
- 替代思路：用流式读取 + 按需解析，避免全量驻留
bufio.NewReader 怎么设缓冲区大小才不白忙？
默认 bufio.NewReader 用 4KB 缓冲，对 SSD 可能还行，但对机械盘或网络文件系统，太小会导致系统调用频繁；设太大又浪费内存且无收益——关键在匹配 I/O 特性，不是越大越好。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 普通 SSD 本地文件：32KB–128KB 是较优区间（
bufio.NewReaderSize(f, 65536)） - 机械盘或 NFS：建议 256KB 起步，但别超 1MB（内核页缓存已做优化，再大收益趋近于零）
- 注意：
bufio.Reader不改变底层*os.File的 seek 行为，但UnreadRune/Peek会占用缓冲区内存，慎用于不定长协议解析
逐行读 bufio.Scanner 为啥有时丢数据或 panic？
它默认单行上限 64KB，超了就直接 Scan() == false 且 Err() 返回 bufio.ErrTooLong —— 很多同学没检查错误，以为“读完了”。
使用场景：日志行、CSV 行、HTTP 响应头等长度可控的文本流。
- 必须显式设置最大长度：
scanner := bufio.NewScanner(f); scanner.Buffer(make([]byte, 4096), 1（第二参数是 max token size） - 如果行长度完全不可控（如混有 base64 大字段），改用
bufio.Reader.ReadString('\n')更稳妥 -
Scanner不支持重用底层Reader的剩余缓冲，每次Scan()后未消费字节会丢失
内存映射 mmap 真比 bufio 快吗？
Go 标准库没直接暴露 mmap，得靠 golang.org/x/sys/unix.Mmap，但它只解决“怎么映射”，不解决“怎么安全读”。实际中，多数情况它并不比调优后的 bufio 快，反而更容易出错。
容易踩的坑：
- 映射区域被其他 goroutine 修改时，Go 运行时无法保证内存可见性（无同步语义）
- 文件 truncate 后继续读映射区会 panic：
signal SIGBUS: bus error - Windows 下需用
syscall.CreateFileMapping，跨平台成本高，且 Go 1.22 前不支持MAP_SYNC等现代特性 - 真正受益的场景极少：只读超大二进制索引文件（如倒排表）、需要随机跳转且 offset 已知
绝大多数业务场景，老实用 bufio.NewReaderSize 配合合理 buffer，再加 io.CopyN 或 io.ReadFull 控制边界，更稳、更易调试、更少隐式依赖。
