直接用 os.ReadFile 读大文件易导致 OOM；应依场景选 bufio.NewReaderSize（如大文本用 64KB）、Scanner 需显式设 Buffer、禁用多 Reader 共享文件句柄、io.CopyBuffer 配 sync.Pool 减 GC 压力。
直接用 os.ReadFile 读大文件，基本等于主动申请 OOM —— 它不缓冲、不流式、不控制内存，几百 MB 就可能卡死或崩溃。真正有效的优化不是“加个 buffer 就完事”，而是根据读取模式选对缓冲工具、设对大小、避开常见引用陷阱。
bufio.NewReaderSize 缓冲大小怎么设才不浪费也不卡顿
默认 4KB 缓冲在 SSD 或高吞吐场景下依然频繁触发 read 系统调用，尤其当单次读取量远小于缓冲区（比如逐字节解析）时，性能瓶颈其实在 syscall 切换上。
- 顺序读大文本（日志、CSV、JSON 流）：用
bufio.NewReaderSize(f, 64*1024)，64KB 对多数 NVMe 和千兆网络更匹配；超过 1MB 反而易引发 CPU cache miss 和 goroutine 阻塞 - 小文件高频读（配置、模板）：32KB 以内足够，再大就是内存浪费
- 定长二进制记录（协议头、索引项）：跳过
bufio，直接复用预分配的[]byte调f.Read(buf)，避免ReadString或ReadLine的长度不确定性
Scanner 逐行读时为什么一行就 panic
bufio.Scanner 默认单行上限 64KB，超长日志行或未切分的 JSON blob 直接触发 scanner.ErrTooLong，不是 bug 是设计保护。
- 必须显式调
scanner.Buffer(make([]byte, 4096), 1<<20)设置最大容量（第二个参数是上限，单位 byte） - 别用
scanner.Bytes()直接存进 map 或 slice —— 它返回的是底层缓冲区切片，整块缓冲区都活不过 GC - 需要保存内容时，用
append([]byte(nil), line...)或直接用scanner.Text()（它已做拷贝）
同一文件套多个 bufio.Reader 会丢数据
bufio.Reader 自己维护底层 *os.File 的偏移量，多个 Reader 并发读同一个文件句柄，必然跳字节、重复读或漏读 —— 这不是竞态，是设计使然。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 绝对不要对同一个
*os.File创建多个bufio.Reader或Scanner - 需要并发处理，用
f.Seek(offset, io.SeekStart)分段定位，每个 goroutine 独立打开或独立 seek 后再套 Reader - 写入同文件更要小心：
bufio.Writer的Flush()不保证原子性，多 writer 必须加锁或串行化
io.CopyBuffer 比 io.Copy 更省 GC
io.Copy 内部硬编码用 32KB 临时切片，每次调用都 make([]byte, 32*1024)，高频小文件拷贝（如微服务中转）会显著抬高 GC 压力。
- 用
sync.Pool预分配缓冲切片：var bufPool = sync.Pool{New: func() interface{} { return make([]byte, 0, 32*1024) }} - 调
io.CopyBuffer(dst, src, bufPool.Get().([]byte))，拷完立刻bufPool.Put(buf) - 注意第三个参数必须是切片（
[]byte），传[32*1024]byte{}会导致每次 new 数组，更差
缓冲区不是越大越好，也不是套了就自动快；真正卡住性能的，往往是 Scanner 的隐式引用、Reader 的偏移错乱、或者 Copy 里没回收的切片 —— 这些问题不会报错，只会让内存悄悄涨、延迟慢慢升。
