bufio.scanner 读超大文件需调大缓冲区防 panic，行长不可控时应换 bufio.reader.readstring；gb 级日志宜用按块读取+状态机解析，避免内存压力与 gc 拖累。
用 bufio.Scanner 读超大文件，但别让它 panic
bufio.Scanner 默认限制单行 64KB，遇到超长行（比如日志里带大段 base64 或 JSON）会直接 panic: bufio.Scanner: token too long。这不是 bug，是设计使然——它优先保障内存安全，不是为解析任意长度行准备的。
解决方法是调大缓冲区上限：
scanner := bufio.NewScanner(file) buf := make([]byte, 1024*1024) // 1MB 缓冲 scanner.Buffer(buf, 1024*1024)
- 第一个参数是底层切片，必须手动分配；第二个是最大 token 长度，不能超过切片容量
- 别设成
math.MaxInt32—— 内存爆掉比 panic 更难排查 - 如果行长度不可控（如混杂二进制数据），
Scanner就不合适了，换bufio.Reader
用 bufio.Reader.ReadString('\n') 精确控制每行边界
当需要处理不规则换行（Windows \r\n、旧 Mac \r）、或要保留末尾换行符时，Scanner 的抽象反而碍事。ReadString 更底层、更可控。
注意它返回的字符串包含终止符（\n 或 \r\n），通常得手动裁掉：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
reader := bufio.NewReader(file)
for {
line, err := reader.ReadString('\n')
if err == io.EOF {
if len(line) > 0 {
// 处理最后一行（无 \n 结尾）
process(line)
}
break
}
if err != nil {
log.Fatal(err)
}
process(strings.TrimSuffix(line, "\n")) // 去掉 \n；若需兼容 \r\n，用 strings.TrimRight(line, "\r\n")
}
-
ReadString遇到\n就停，不管前面有没有\r，所以跨平台时得自己清理 - 它不会跳过空行，也不会合并连续换行符——行为完全透明
- 比
Scanner稍慢一点，但稳定性和可预测性高得多
按块读取 + 手动分界：真正应对 GB 级日志的方案
当文件大到内存吃紧（比如 50GB 日志），哪怕逐行读，频繁的 string 分配和 GC 也会拖慢速度。这时应放弃“按行”抽象，改用“按块”+“状态机”方式解析。
核心思路：用 io.ReadFull 或 reader.Read 一批批读入 []byte，在字节流里找 \n 位置，切出完整行，把跨块的残缺行缓存起来。
- 避免反复转换
[]byte↔string，尤其对长行，unsafe.String可零拷贝转（Go 1.20+） - 缓存未完成行的变量必须是局部的，不能复用全局
bytes.Buffer——并发读多个文件时会错乱 - 别用
strings.Split处理整块数据：它会把整个块加载进内存再切，失去流式优势
性能关键点：文件打开模式和系统调用开销
用 os.Open 没问题，但别在循环里反复 os.Open → defer file.Close()——系统调用成本高。超大文件建议一次打开，全程复用句柄。
- Linux 下可加
O_DIRECT标志绕过页缓存（需对齐 512B），但 Go 标准库不直接支持，得用syscall.Open+ 自己管理 buffer - SSD 上顺序读基本打不满带宽，瓶颈常在 Go runtime 的内存分配和 GC，而非磁盘 IO
- 如果后续要正则匹配或 JSON 解析，别在读取时做——先写入 channel 或临时 slice，让 worker goroutine 并行处理
最易被忽略的是：不同行结束符在不同系统上表现不一，而 bufio.Scanner 和 ReadString('\n') 都只认 \n。如果你的文件来自 Windows 或老系统，且没预处理，第一行就可能读不全。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
