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 不支持回退 - 对含 \r\n、\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 边界。
