Go bufio.Scanner 遇到超长行怎么办：Buffer 上限与流式读取取舍

线上日志采集程序突然少了一批记录，检查错误时只看到 bufio.Scanner: token too long，也就是本文图中标出的 ErrTooLong。这不是文件损坏，而是 Scanner 为单个 token 设置了缓冲上限；如果一行日志可能超过默认范围，就要在扫描前明确调大 Buffer，或者换成按分隔符读取、不会把整行一次性塞进 Scanner 的方案。

先复现 Scanner 为什么会停在半路

先准备一个包含长行的输入。示例把一行扩到 128 KiB，足以触发一个偏保守的 Scanner 配置：

package main

import (
    "bufio"
    "fmt"
    "strings"
)

func main() {
    input := "ok\\n" + strings.Repeat("x", 128*1024) + "\\nlast\\n"
    scanner := bufio.NewScanner(strings.NewReader(input))
    for scanner.Scan() {
        fmt.Println("line bytes:", len(scanner.Bytes()))
    }
    fmt.Println("scan error:", scanner.Err())
}

输出中通常只能看到第一行，随后 Err() 返回 bufio.Scanner: token too long。这里有两个容易漏掉的点：Scanner 的循环不会替你抛出异常；另外，已经读出的前缀不等于完整的一行，不能在错误后继续把 Scanner 当作可靠的完整记录流。

图：默认 token 上限挡住长日志行，调整合法上限后才继续收口。

把 Buffer 调整放在第一次 Scan 之前

Buffer 要在第一次调用 Scan 前设置。第一个参数是初始缓冲区，第二个参数是单个 token 允许使用的最大容量；它不是“本次读取多少字节”的批量参数。

const maxLine = 512 * 1024

scanner := bufio.NewScanner(reader)
scanner.Buffer(make([]byte, 32*1024), maxLine)
for scanner.Scan() {
    line := scanner.Bytes()
    // 如果后续要异步处理，先复制 line；下一次 Scan 会复用底层缓冲区。
    handle(append([]byte(nil), line...))
}
if err := scanner.Err(); err != nil {
    return fmt.Errorf("read log line: %w", err)
}

上限应该来自业务约束，而不是随手写成几个很大的 GB。比如日志协议规定单行不超过 512 KiB，就把 Buffer 512 KiB 作为明确预算，超出部分视为坏记录并记录指标；满足约束后才算“继续扫描”。如果协议没有上限，盲目把它调到几十 MiB 只会把异常输入转化成内存压力。

为什么 Bytes 不能直接交给异步任务

Bytes() 返回的切片只在下一次扫描前稳定。把它放进 channel 后再扫描下一行，接收方可能读到已被覆盖的内容。同步解析可以直接使用；跨 goroutine、批量入队或延迟写入时，应复制到独立切片，或者使用 Text() 生成字符串。

行长没有可靠上限时换成 Reader 分段

当输入来自用户上传、外部日志或未知协议，单行可能很大，Scanner 的最大 token 仍会成为硬上限。此时可以用 ReadLine 分段读取，再决定是否拼接、截断或拒绝：

reader := bufio.NewReader(r)
var line []byte
for {
    part, isPrefix, err := reader.ReadLine()
    if err != nil {
        if err == io.EOF && len(line) == 0 {
            break
        }
        return err
    }
    line = append(line, part...)
    if !isPrefix {
        handleLine(line)
        line = line[:0]
    }
    if len(line) > maxAllowed {
        return fmt.Errorf("line exceeds %d bytes", maxAllowed)
    }
}

isPrefix=true 表示换行符还没出现，代码可以在拼接前按“长度预算”做上限判断；超过预算就执行“超限拒绝”。若业务只需要提取时间戳和级别，不必保存整行，可以在分段时完成状态机解析，把内存占用限制在固定范围；若必须保留完整原文，则仍要为最大行长设定可接受的预算。

图：已知合法上限时调大 Scanner，未知长度时用 Reader 分段并在预算处收口。

把选择写进流水线的门禁和复查

这类问题常发生在采集流水线的中间环节，修复代码后还要把检查点补上。至少保留三项指标：最长合法行长度、超限行数量、读取错误数量。压测时分别测试 4 KiB、128 KiB、接近上限和超过上限的输入，确认程序在边界处是明确拒绝还是按约定截断。

• 日志协议有明确上限：用 Scanner.Buffer，并在 Err() 非空时终止当前文件处理。
• 记录可能远超内存预算：用 Reader.ReadLine 分段，边读边解析，必要时拒绝超限记录。
• 需要把扫描结果交给异步消费者：复制 Bytes() 内容，避免下一次 Scan 覆盖数据。

不要只用“文件读完了”作为成功条件。对 Scanner 来说，循环结束可能是正常 EOF，也可能是 token 太长；只有 Err() == nil，并且读到的记录数、最大长度和输入预期一致，才算这一轮通过。

相关问题

Scanner 的最大 token 能设置成 0 吗？

不能把 0 当作“无限大”使用。应根据协议和内存预算设置明确上限；没有可靠上限时选择 Reader 分段。

调大 Buffer 后还需要复制 Bytes 吗？

需要。Buffer 只改变容量，不改变 Scanner 复用扫描缓冲区的语义；异步或延迟处理仍应复制。

ReadString 和 ReadLine 应该怎么选？

需要完整字符串且行长有预算时可用 ReadString；需要控制分段、提前拒绝超限或边读边解析时，ReadLine 更容易建立内存门禁。

最后的判断

短而有明确协议上限的文本，Scanner 配合 Buffer 和 Err 检查足够简单；输入边界不可信时，Reader 分段更稳。关键不是把上限调到足够大，而是让“最长合法行、超限行为、异步复制和验证指标”成为代码里看得见的约束。