bufio.Scanner 默认爆内存因64KB缓冲区限制，超长行直接报错且无法跳过；大文件下小字符串频繁分配加剧GC压力；应依行长分布设Buffer，超长行场景宜换bufio.Reader手动控制。
为什么 bufio.Scanner 默认会爆内存读大文件
因为它的默认缓冲区只有 64KB，一旦某行超过这个长度（比如日志里带超长堆栈或 Base64 内容），scanner.Scan() 就直接返回 false，且 scanner.Err() 报 bufio.Scanner: token too long —— 它不会跳过这行继续读，而是彻底失败。
更隐蔽的问题是：哪怕所有行都短，只要文件极大（比如 50GB），反复调用 scanner.Text() 产生的小字符串切片+内存分配累积起来，GC 压力也会陡增，实际吞吐反而下降。
- 别靠增大
BufSize硬扛超长行，1MB 缓冲区对 10MB 的单行日志仍无效 -
scanner.Split()自定义分隔符时，若逻辑有误（比如没处理换行符边界），容易漏数据或 panic - 用
scanner.Bytes()替代Text()可避免一次拷贝，但要注意返回的[]byte是缓冲区内存引用，循环中必须append([]byte{}, ...)复制出来再用
如何安全地把 bufio.Scanner 缓冲区调到够用又不浪费
关键不是“越大越好”，而是匹配你的日志行长分布。先用 head -n 1000 huge.log | awk '{print length}' | sort -n | tail -1 粗估最大行长，再加 20% 余量设为缓冲区。
实操上必须显式调用 scanner.Buffer()，而且要在 scanner.Scan() 调用前设置：
立即学习“go语言免费学习笔记（深入）”；
scanner := bufio.NewScanner(file) // 必须在 Scan() 之前设置，否则无效 scanner.Buffer(make([]byte, 1024*1024), 1024*1024) // 1MB 缓冲区和最大令牌长度
- 第一个参数是底层数组，第二个是允许的最大 token 长度（即单行上限）
- 两个值可以不同：数组可稍大（便于复用），但最大 token 长度必须 ≥ 你预期的最长行
- 如果设了 1MB 缓冲区但最大 token 长度只设 64KB，照样报错
遇到超长行时，用 bufio.Reader 手动读取更可控
Scanner 是为“按行可预测”场景设计的；当日志出现不可控长行（如 JSON 日志嵌套过深、二进制 dump 混入文本），它就退化成负担。这时该切到 bufio.Reader + ReadString('\n') 或 ReadBytes('\n')。
优势在于你能捕获并处理异常：
reader := bufio.NewReader(file)
for {
line, err := reader.ReadString('\n')
if err == io.EOF {
if len(line) > 0 { /* 处理最后一行无换行符的情况 */ }
break
}
if err != nil {
// 比如 line 超过 10MB？这里可以记录警告、截断或跳过
log.Warn("skipping oversized line:", len(line))
continue
}
// 正常处理 line
}-
ReadString返回string，适合后续正则或 JSON 解析；ReadBytes返回[]byte，零拷贝但要注意末尾含\n - 务必检查
io.EOF和len(line) > 0，否则最后一行可能丢失 - 没有内置缓冲区上限，但你要自己控制单次读取的容忍长度，比如用
io.LimitReader(reader, maxLineSize)包一层防 OOM
性能对比：Scanner vs Reader 在真实日志场景下的取舍
在纯 ASCII 行长 Scanner 因预分配和内联优化，比 Reader.ReadString 快 10–15%；但一旦混入几条 10MB 的错误堆栈，Scanner 会卡住或崩溃，而 Reader 可稳定降级处理。
- 高吞吐 + 行长稳定 → 用
Scanner，配好Buffer() - 需容错 + 行长波动大 → 切
Reader，自己管边界和错误 - 千万别在
Scanner报错后试图 “重置” 它继续读 —— 底层状态已损坏，必须新建实例或换 Reader
真正难的不是调哪个参数，而是日志格式本身是否隐含不可靠性：比如前端埋点日志里塞了用户输入的未过滤字段，这种源头问题，再好的缓冲区配置也救不了。
