os.ReadFile会一次性将整个文件加载到内存导致OOM，适合小文件；大文件应使用bufio.Scanner分块读取或手动Read控制缓冲区。
os.ReadFile 为什么一读就 OOM
因为 os.ReadFile 会把整个文件一次性 malloc 到内存里——2GB 日志进来，进程瞬间申请 2GB 堆空间，Go 的 GC 来不及回收，系统直接 KILL。这不是 bug，是设计使然：它只适合配置文件、小 JSON 这类“全量加载即结束”的场景。
- 真实业务中你几乎从不需要整份驻留，比如日志逐行过滤、视频帧解码、CSV 行解析，都是边读边处理
- 哪怕只是调用一次
bytes.Buffer.ReadFrom(r)或ioutil.ReadAll()（已弃用），效果等同于os.ReadFile - 更隐蔽的坑：
bufio.NewReader(file).ReadString('\n')看似流式，但底层仍可能缓存大量未消费数据，尤其遇到超长无换行字段时
用 bufio.Scanner 安全分行读文本大文件
bufio.Scanner 是处理 GB 级日志、JSON Lines、纯文本最省心的选择，它自动分块、按需分配、不攒整文件，但默认配置容易翻车。
- 默认单行缓冲上限是 64KB，遇到含 base64 图片或超长 traceID 的日志，会 panic 报
scanner: token too long - 必须显式调
scanner.Buffer(make([]byte, 64*1024), 10*1024*1024)：第一个参数是初始缓冲，第二个是最大允许长度 -
scanner.Text()返回的是当前缓冲区内的拷贝，安全；但若后续要字节操作（如跳过 BOM、校验 CRC），改用scanner.Bytes()避免 string 转换开销 - 最后一行没换行符？
scanner.Scan()在 EOF 时仍会返回该行，无需额外判断——前提是没触发上面那个缓冲溢出
手动 Read 分块处理二进制或自定义格式
当文件不是文本（比如 protobuf 流、加密块、固定 1MB 帧结构），就得绕过 Scanner，用 file.Read() 自控节奏。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 预分配一个
buf := make([]byte, 4*1024*1024)（4MB），在 for 循环里反复重用，别每次 new - 用
n, err := file.Read(buf)，而不是io.ReadFull：后者在最后一块不足长度时直接返回io.ErrUnexpectedEOF，而这是正常结束信号 - 正确判断 EOF：
if n > 0 && err == io.EOF→ 最后一块，数据有效；if n == 0 && err == io.EOF→ 真空文件或刚读完 - 写入目标时，务必传
buf[:n]，而非整个buf，否则可能把上一轮残留脏数据一起写进去
io.CopyBuffer 写慢盘/网络文件必须调大缓冲区
io.Copy 看似简单，但在 NFS、Ceph、USB 盘或高延迟云盘上，默认 32KB 缓冲会让吞吐暴跌，甚至卡死报 broken pipe。
立即学习“go语言免费学习笔记（深入）”；
- 原因不是函数不行，是小块 write 导致 syscall 过多 + 等待时间叠加；实测把缓冲设成
make([]byte, 1024*1024)（1MB），NFS 上提速 3–5 倍 - 别用
sync.Pool复用这个缓冲区：压测反而更慢——Pool 的锁和指针跳转成本，在微秒级使用周期里盖过了内存节省 - 如果目标是 HTTP 响应体且上游不可控（比如代理转发），加一层
time.AfterFunc监控单次Write超时，主动断连防僵死
真正难的从来不是“怎么读”，而是读到一半出错时是否关了 *os.File、最后一块边界有没有漏处理、缓冲区大小是不是在磁盘 IO 特性与内存占用间取了平衡点——这些细节不写进日志，就只能靠 pprof 和 strace 晚上加班抓。
