Golang bufio Scanner读取大文本限制说明_逐行读取注意事项

bufio.Scanner 默认缓冲区仅64KB，超长行会报“Token too long”错误；可通过scanner.Buffer()扩大上限，但更稳健的做法是改用bufio.Reader.ReadString()，它无内置长度限制且支持回退。

Scanner 默认缓冲区只有 64KB，超长行直接报错

当你用 bufio.Scanner 读取日志、csv 或自定义分隔的大文本时，如果某一行长度超过 64 * 1024 字节（即 64KB），Scan() 会返回 false，且 Err() 返回 "bufio.Scanner: token too long"。这不是 EOF，而是缓冲区撑爆了。

根本原因：Scanner 内部用固定大小的 bytes.Buffer 累积输入，直到遇到换行符；它不自动扩容，也不提示“快满了”，只在溢出时硬报错。

• 不能靠 scanner.Bytes() 或 scanner.Text() 拿到超长行内容——它们都返回空或 panic 前的残留
• 即使你只调用 scanner.Scan() 判断是否还有行，也会卡在这行失败
• 该限制与操作系统、go 版本无关，是 Scanner 自身设计决定的

修改 MaxScanTokenSize 可临时绕过，但有风险

你可以通过 scanner.Buffer() 手动扩大缓冲区上限，例如支持最大 1MB 的单行：

scanner := bufio.NewScanner(file) scanner.Buffer(make([]byte, 64*1024), 1024*1024)

注意两个参数：initial 是初始切片大小，max 是允许的最大令牌（token）长度。后者必须显式设大，否则仍走默认 64KB。

立即学习“go语言免费学习笔记（深入）”；

• 增大 max 不等于内存常驻——Buffer 底层用 slice，实际只分配当前需要的容量
• 但若文本中真存在几 MB 的单行（比如嵌套 jsON、base64 blob），这个设置会让 GC 压力变大，且可能被恶意输入拖垮服务
• 不建议无脑设成 math.MaxInt32，那等于放弃保护机制

真正稳健的方案：改用 bufio.Reader + ReadString(‘n’)

当无法控制输入格式（如日志混入超长 trace ID、未转义的二进制 dump），bufio.Scanner 就不该是首选。换成 bufio.Reader 更可控：

reader := bufio.NewReader(file) for {     line, err := reader.ReadString('n')     if err != nil {         if err == io.EOF && len(line) > 0 {             // 处理最后一行无换行符的情况             processline(line)             break         }         if err != io.EOF {             log.Fatal(err)         }         break     }     processLine(line) }

ReadString 没有内置长度限制，它边读边 append 到内部 buffer，实际受可用内存约束。你还可以配合 io.LimitReader 或手动检查 len(line) 做业务级截断或告警。

• 比 Scanner 多写几行，但逻辑透明，错误路径清晰
• 可随时插入 reader.UnreadRune() 回退解析，Scanner 不支持回退
• 对含 rn、r 的跨平台文本，需额外处理；而 Scanner 默认已做 normalize（可通过 Split 自定义）

逐行读取性能差异其实很小，别迷信 Scanner

很多人以为 Scanner “更快”是因为用了预分配 buffer，但实测在普通 SSD 或内存文件上，Reader.ReadString 和 Scanner 的吞吐差距通常

• 用 go test -bench=. 对比时，记得关闭 GC（GOGC=off）并复用 buffer，否则 GC 开销会掩盖真实差异
• Scanner 的 split 函数（如 ScanLines）如果被替换成自定义逻辑（比如跳过注释、合并续行），维护成本远高于 Reader + 手动字符串处理
• 如果你需要按字段切分（如 CSV），直接上 encoding/csv，别自己用 Scanner 拆——它不处理引号转义

真正容易被忽略的是：Scanner 的错误模型是“全有或全无”，一旦某行失败，你无法知道前面多少行已成功处理；而 Reader 让你能精确控制每一步的 success/fail 边界。