Go Scanner 长行 token 超限的缓冲区处理

Go 的 bufio.Scanner 遇到长行并返回 token too long，应在第一次Scan之前调用Buffer，提供初始缓冲和合理的增长预算，并在循环结束后检查Err。不能在超限之后修改同一个Scanner继续扫描，也不能把Scan返回false直接当成正常文件结束。

官方地址：https://pkg.go.dev/bufio#Scanner.Buffer

假设一个逐行统计工具读小样本正常，换成长文本记录后只给出部分行数。我会先确认单条记录是否超出扫描预算，再决定继续使用Scanner还是改用分片读取。下面做一个完整的小工具，重点是错误时不交付貌似成功的部分结果；不虚构实测经历或性能收益。

超限的是单个token，不是整个文件

Scanner默认用ScanLines切分文本行，并去掉行终止符。文件可以很大，只要每个token能在扫描预算中容纳，就不必把全文加载到内存。相反，一个很小但只有一条超长记录的文件，也可能触发错误。

默认最大扫描token大小由MaxScanTokenSize定义，其值为64×1024；实际能接受的内容还取决于分隔符和扫描所需空间，不能把这个数当作“恰好65536字节内容必然成功”的协议承诺。UTF-8字节数也不等于字符数。

把初始容量和业务上限分别写清楚

Buffer的第一个参数用于初始缓冲，第二个参数控制扫描时可分配缓冲的最大规模。两者都不是文件总大小。官方文档还指出，token大小受max与cap(buf)中较大值约束，因此预先传入一个特别大的切片，不能靠较小max把它重新压成严格业务限额。

我的选择是较小初始缓冲、明确的扫描预算，再对拿到的行内容检查业务长度。本文示例允许单行内容最多1 MiB，初始容量32 KiB，扫描预算2 MiB；这些是自主选定的示例值，为正常行尾与扫描判断保留余量，不是标准库推荐配置。

写成只在完整成功时输出的统计工具

将以下内容保存为main.go。程序接收一个文件参数，逐行统计；打开、扫描或关闭失败都会产生非零退出码。超长内容不会静默跳过。

package main

import (
    "bufio"
    "fmt"
    "io"
    "os"
)

const lineLimit = 1  lineLimit {
            return 0, fmt.Errorf("line %d exceeds content limit", count+1)
        }
        // 只同步消费当前token，不保留会被下一次Scan覆盖的切片。
        count++
    }
    if err := s.Err(); err != nil {
        // 出错时拒绝把此前的部分统计作为完整结果返回。
        return 0, fmt.Errorf("scan after %d complete lines: %w", count, err)
    }
    return count, nil
}

func run() error {
    if len(os.Args) != 2 {
        return fmt.Errorf("usage: linecount FILE")
    }
    f, err := os.Open(os.Args[1])
    if err != nil {
        return fmt.Errorf("open input: %w", err)
    }
    count, scanErr := countLines(f)
    closeErr := f.Close() // 关闭文件后再统一决定是否输出成功结果。
    if scanErr != nil {
        return scanErr
    }
    if closeErr != nil {
        return fmt.Errorf("close input: %w", closeErr)
    }
    _, err = fmt.Printf("lines=%d\n", count)
    return err
}

func main() {
    if err := run(); err != nil {
        fmt.Fprintln(os.Stderr, err)
        os.Exit(1) // run已完成文件清理，非零退出供调用方识别失败。
    }
}

在安装Go工具链的目录中，可以按下面的命令运行；示例文件路径由读者替换：

# 读取自己的文本文件；错误退出时不要把部分统计当成完整结果。
go run main.go ./input.txt

代码和命令未在本文环境运行，因此不展示虚构输出。成功时程序只打印行数；调用方还应检查退出码。业务上限检查失败与Scanner内部超限属于不同错误路径，二者都停止本次统计。

Bytes的生命周期也要跟着处理方式调整

例子只在当前Scan内同步计算长度，因此可用 s.Bytes()。返回切片可能引用Scanner复用的底层数组，下一次扫描可能覆盖它。若把每一行交给异步工作队列，必须复制需要保留的字节，并限制队列容量。

s.Text() 返回包含当前token字节的新字符串，使用简单，但不能据此认为保存所有Text结果就没有内存成本。Scanner减少的是整文件一次读取的需要，下游仍可因为积压或全量保存记录耗尽内存。

出错后为什么不能在同一个流上重新建Scanner接着读？

官方文档说明，Scanner遇到EOF、首个I/O错误或超大token后会不可恢复地停止，底层Reader还可能已经前进到最后一个已交付token之后较远的位置。此时直接给同一个Reader套一个新Scanner，可能丢失尚未处理的缓冲数据。

如果输入是可重新打开且稳定的文件，可以从文件开头重跑；但若此前已产生写库等副作用，重跑还需要幂等或进度设计。本文只在完整成功时返回统计结果，所以不会对外提交部分行数；它不替带副作用的导入器解决重复写入。

对于必须允许极长记录、需要跳过坏行后继续、或必须精确控制读取位置的任务，更适合设计 bufio.Reader 分片消费。ReadSlice在缓冲不足时可以返回片段，但调用方必须处理ErrBufferFull、行尾和累计预算；ReadString会积累整行，不能仅换个API名称就宣称消除了长行内存成本。

集成时覆盖这些边界

这张表是建议的回归场景，不是已执行的测试报告。并发处理多个文件时，还要结合同时存活的Scanner数量、最大记录和业务对象预算估算内存；扩大每个Scanner的预算会放大并发时的资源需求。

相关问题

Buffer放在for循环里能动态扩容吗？

不能。开始扫描后再调用Buffer会panic；应在首次Scan之前完成Buffer和Split配置。

把max设为一个很大的整数就好了吗？

这只是放宽潜在分配预算，并没有定义可以接受的业务输入。明确最大记录长度更容易控制资源和拒绝行为。

换成ScanWords就不会超限了吗？

token含义会从行变成单词，但超长无分隔片段仍可能超过预算。换切分规则还会改变业务语义，不能为绕过错误随意替换。

对于最大记录长度已知的小工具，我倾向保留Scanner的简洁接口，提前配置容量并检查Err；需要精细恢复或极长记录时，则直接设计Reader的分片协议。

参考：Scanner缓冲配置；Scanner停止与读取位置；Reader分片读取。