bufio.Scanner 默认缓存整行易致内存爆炸，遇超长行或大文件可能触发 ErrTooLong 或 OOM；适合行短可控文本，非 GB 级日志场景；若必须使用，应先调用 scanner.Buffer(make([]byte, 64*1024), 1
用 bufio.Scanner 读大文件？小心内存爆炸
默认的 bufio.Scanner 会把整行缓存进内存，遇到超长行（比如日志里带超长 base64 字段）或超大文件，很容易触发 scanner.ErrTooLong 或直接 OOM。它适合处理“行短且可控”的文本，不是为 GB 级日志或 dump 文件设计的。
实操建议：
- 如果必须用
Scanner，先调scanner.Buffer(make([]byte, 64*1024), 1 扩容缓冲区，但上限仍受制于单行长度 - 对真正的大文件，优先放弃
Scanner，改用bufio.Reader+ 手动分块读取 - 别依赖
ScanLines的便利性——它不解决底层按需加载问题
用 bufio.Reader.ReadSlice('\n') 还是 ReadBytes？
ReadSlice 复用内部 buffer，零分配；ReadBytes 每次都 new slice，GC 压力明显。但 ReadSlice 有陷阱：它返回的是底层 buffer 的切片，一旦下一次 ReadSlice 被调用，前一次返回的字节可能被覆盖。
安全写法：
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 立刻拷贝：用
append([]byte{}, line...)或bytes.Clone(line)（Go 1.20+） - 避免跨 goroutine 传递原始
ReadSlice返回值 - 若只做简单匹配（如 grep）、不保留内容，可直接用
ReadSlice省分配
逐块读取时，io.Copy 和 io.CopyBuffer 性能差多少？
对纯管道式处理（如大文件压缩、加密、转码），io.Copy 内部用 32KB 默认 buffer；io.CopyBuffer 允许你传入自定义 buffer（比如 1MB），在 SSD 或高速网络盘上吞吐可提升 2–5 倍。
注意点：
- buffer 太大会增加单次系统调用延迟，一般 256KB–1MB 是较优区间
- buffer 必须复用：
buf := make([]byte, 1 在循环外声明，传给 <code>io.CopyBuffer(dst, src, buf) - 不要用
make([]byte, 0, 1——容量没用，<code>CopyBuffer只看 len
内存映射 mmap 适合 Golang 大文件吗？
Go 标准库不提供跨平台 mmap，得靠 golang.org/x/sys/unix（Linux/macOS）或 golang.org/x/sys/windows（Windows）。它确实能绕过内核 copy，对随机访问（如数据库索引扫描）友好，但对顺序流式处理收益有限，且引入 SIGBUS 风险（文件被截断或 unmap 后访问）。
是否值得上：
- 文件 >10GB 且需频繁跳转读取 → 可考虑
- 只是从头到尾扫一遍 →
bufio.Reader+ 合理 buffer 更稳 - 部署环境不确定（容器、FUSE、NFS）→ mmap 行为不可控，慎用
最常被忽略的一点：无论用哪种方式，都要显式关闭文件句柄。大文件场景下 os.File 不及时 Close()，容易触达系统级 ulimit -n 限制，后续 Open 直接失败。
