应避免用 os.ReadFile 读取超大文件，因其一次性加载全量数据导致内存激增、OOM 风险高；推荐 os.Open + bufio.Scanner 流式逐行处理，内存恒定、可控且安全。
别用 os.ReadFile，它会把整个文件 malloc 到内存里——1.3GB 日志直接吃掉 4GB 堆，进程被 OOM kill 是常态。
为什么 os.ReadFile 不适合超大文件
它内部调用 io.ReadAll，一次性分配足够容纳全部内容的 []byte。实测读取 1.3GB 文件时：TotalAlloc 达到 5356MB，Alloc 持有 4332MB，且耗时超 2 秒。这不是 bug，是设计定位：只适合几 KB 的 config.json 或 token 文件。
- 内存峰值 ≈ 文件大小 + 内部开销（约 10–20%）
- GC 压力陡增，尤其在频繁调用场景下
- 无法中断、无法限速、无法边读边丢弃
用 os.Open + bufio.Scanner 流式逐行处理
这是最省心、内存恒定、吞吐可控的起点。每行只保留当前副本，典型内存占用稳定在几 MB 级别。
- 必须提前调
scanner.Buffer(make([]byte, 64*1024), 10*1024*1024)—— 否则默认单行上限 64KB，遇到含 base64 或长 traceID 的日志会 panic 报scanner: token too long - 用
scanner.Text()安全（已拷贝），scanner.Bytes()快但共享底层缓冲——若存进map或[]string，整块缓冲区都活不过 GC - 检查
scanner.Err()：权限错误、磁盘损坏等不会 panic，但会静默跳过剩余内容 - 循环内禁止阻塞：同步发 HTTP、直写 DB、无 timeout 的
time.Sleep都会导致后续所有行堵在缓冲区，吞吐归零
需要按块读取（非按行）时用 bufio.Reader + Read
适用于二进制解析、固定长度记录、或需自定义分隔符的场景，比 Scanner 更底层、更灵活。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 分配固定大小缓冲区，例如
buf := make([]byte, 64*1024)，反复r.Read(buf) -
Read返回实际读取字节数n和err；io.EOF表示结束，其他err需显式处理 - 避免用
ReadFull处理末尾不完整块——它会在不足时返回io.ErrUnexpectedEOF，需额外判断 - 如需复用缓冲内存，可结合
sync.Pool，但注意 pool 中对象生命周期不可控，不适合持有外部引用
写入也得配套优化：别让读快写慢拖垮流水线
流式读取后若要写入新文件，同样不能每行一次 os.File.Write —— 百万行实测耗时翻 3–5 倍，CPU 全耗在 syscall 上。
- 用
bufio.NewWriterSize(f, 1 创建带缓冲的写入器（建议 64KB） - 每次写完记得
w.Flush()——defer w.Flush()不可靠，失败可能发生在中间 - 目标是实时输出（如
os.Stderr），可定期调log.Writer().(*bufio.Writer).Flush() - 并发写多个文件时，每个文件配独立
bufio.Writer，避免共享锁竞争
真正难的不是“怎么读”，而是“读完之后怎么不卡住、不爆内存、不丢错、不漏处理”。bufio.Scanner 提供了极简接口，但它的默认行为和边界条件（比如缓冲、错误传播、数据所有权）恰恰是线上故障最常见的源头。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
