当前位置：首页 > 文章列表 > Golang > Go问答 > Go bufio.Scanner 遇到 token too long 怎么办：大日志行的长度上限与内存取舍

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

来源：17golang原创 2026-07-22 15:22:41 0浏览收藏

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

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

要点速览

默认Scanner适合普通短行，不适合未经约束的大JSON或堆栈字段。
Scanner.Buffer 的第二个参数是单个token的最大容量，不是整个文件大小。
把上限设为2 MiB只是示例，生产值应来自日志样本和峰值内存预算。
需要处理超长行且不想一次性持有完整内容时，应考虑 bufio.Reader 分块拼接。

默认上限为什么会把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)
}

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

Go bufio.Scanner 读取 access.log 时，短日志行通过而超长 JSON 行触发 token too long

先量出单行峰值，再决定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() 内容、进程峰值内存。只看“程序没有报错”还不够，超长行是否被完整传给解析器也要核对。

方案	超长行	内存特征	适合场景
默认 Scanner	可能返回 token too long	缓冲边界小	短日志、协议行
Scanner.Buffer	可覆盖明确上限	单行上限内可能扩容	行长可控的 JSON 日志
Reader 分块	可自行拼接或流式处理	按块控制内存	行长不可控、需要限流

实验里还应故意加入一条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的内部缓冲，跨轮次保存时必须复制或追加到自己的切片。若只需要统计、过滤或转发，也可以边读边处理，避免拼出完整大行。