Go bufio.Scanner 遇到 token too long 怎么办：大日志行的长度上限与内存取舍

线上日志清洗程序突然漏掉几条请求记录，日志里最明显的一行是 bufio.Scanner: token too long。这通常不是文件损坏，而是某条JSON日志超过了Scanner的默认token上限。先把上限调到能覆盖真实数据的范围，并检查单行峰值；如果日志行可能持续变大，直接改用分块读取更稳妥。

token过长报错不是Scanner的bug，是它主动做的内存保护，你需要根据自己的业务日志特征，在最大行长和内存占用之间选一个可控的平衡点，而不是直接把上限改成无限制。

默认上限为什么会把access.log读到一半

Scanner 按分隔符扫描token，逐行读取时分隔符就是换行。它默认准备的缓冲区并不适合一条带完整 request_body 的JSON日志。只要某一行超过可接受的token大小，Scan() 会返回false，真正原因要通过 Err() 读取。

scanner := bufio.NewScanner(file)
for scanner.Scan() {
    handle(scanner.Bytes())
}
if err := scanner.Err(); err != nil {
    log.Printf("read access.log: %v", err)
}

这里最容易漏掉的是最后三行：如果只判断循环结束，就会把“读完了”和“中途失败”混为一谈。先记录错误，再统计失败发生前已经处理了多少行，基线才有意义。

先量出单行峰值，再决定Scanner.Buffer的大小

修复前可以对一份脱敏日志做一次扫描，记录每行字节数的最大值。不要只看平均值：平均4 KB的日志里混入一条1.6 MB的请求体，仍然会击穿默认配置。

scanner := bufio.NewScanner(file)
maxBytes := 0
lines := 0
for scanner.Scan() {
    lines++
    if n := len(scanner.Bytes()); n > maxBytes {
        maxBytes = n
    }
}
fmt.Printf("lines=%d max_line_bytes=%d err=%v\n", lines, maxBytes, scanner.Err())

假设样本得到的峰值是1.3 MiB，且日志格式有明确上限，可以先给2 MiB的余量。这个数字不是通用答案，重点是把它和单行大小、并发读取协程数放在同一张预算表里。

Scanner.Buffer的两个参数分别控制什么

第一个参数是初始缓冲区，第二个参数是单个token允许达到的最大容量。它们都应在第一次调用 Scan() 之前设置；一旦扫描开始，再修改配置就太晚了。

scanner := bufio.NewScanner(file)
scanner.Buffer(make([]byte, 64*1024), 2*1024*1024)
for scanner.Scan() {
    handle(scanner.Bytes())
}
if err := scanner.Err(); err != nil {
    return fmt.Errorf("scan access.log: %w", err)
}

64 KiB是起始容量，2 MiB是单行上限。多数短行不会立刻占满2 MiB，但当异常行到来时，扫描器仍可能扩容到该边界。部署前要用峰值并发估算“每个扫描器可能持有多少缓冲”，而不是把最大值随手改成几十兆。

用一个小实验比较修复前后的结果

可以生成一份包含8 KB普通行和1.3 MB JSON行的样本，分别跑默认配置与2 MiB配置。关注三个量：成功处理的行数、Err() 内容、进程峰值内存。只看“程序没有报错”还不够，超长行是否被完整传给解析器也要核对。

实验里还应故意加入一条2.1 MiB的行，确认程序会在预期边界失败，而不是无限分配。边界错误是有价值的结果，它告诉你日志生产方的字段约束已经失守。

行长不可控时，换成Reader分块读取

如果日志中允许上传内容、堆栈或压缩后的字段，单行长度可能没有可靠上限。此时继续把Scanner的最大值调大，只是把风险向堆内存推迟。可以用 bufio.Reader.ReadSlice 逐块取数据，在遇到换行前限制累计字节数。

reader := bufio.NewReaderSize(file, 64*1024)
const maxLine = 2 * 1024 * 1024
var line []byte
for {
    part, err := reader.ReadSlice('\n')
    line = append(line, part...)
    if len(line) > maxLine {
        return fmt.Errorf("access.log line exceeds %d bytes", maxLine)
    }
    if err == nil {
        handle(line[:len(line)-1])
        line = line[:0]
        continue
    }
    if errors.Is(err, io.EOF) {
        if len(line) > 0 { handle(line) }
        break
    }
    if !errors.Is(err, bufio.ErrBufferFull) {
        return err
    }
}

真实代码要注意 ReadSlice 返回的片段可能指向Reader的内部缓冲，跨轮次保存时必须复制或追加到自己的切片。若只需要统计、过滤或转发，也可以边读边处理，避免拼出完整大行。

常见问题：Scanner的长度和内存边界怎么判断

把Scanner.Buffer的最大值设成64 MB可以吗？

技术上可以，但不代表应该这样做。先统计单行峰值，再乘以并发扫描数和解析阶段的临时对象，确认进程内存预算能承受；没有行长约束时优先采用分块策略。

为什么Scan返回false但Err是nil？

读到正常文件末尾时就是这种结果。只有在循环结束后检查 Err()，才能区分EOF和token超限、底层I/O失败等异常。

scanner.Bytes()返回的数据能长期保存吗？

它指向Scanner当前缓冲区，下一次扫描后内容可能被复用。需要异步处理或跨循环保存时，应复制到自己的字节切片。

什么时候必须放弃Scanner？

当单行长度没有可靠上限、需要流式解析，或需要区分并处理超长片段时，Reader更容易把内存、超时和拒绝策略写清楚。

把长度上限当成日志协议的一部分

token too long 修好后，别只把代码提交掉。给日志生产方增加字段大小约束，给清洗程序记录最大行字节数和超限计数，再用一份包含异常长行的回归样本跑一次。这样下次字段膨胀时，告警会先出现，程序不会悄悄少处理几条记录。