Go问答：bufio.Scanner读取长行为什么提前停止怎样安全扩展缓冲区

用 bufio.Scanner 按行读取日志、导入文件或文本协议时，最容易误判的一种现象是：循环突然结束，后面还有数据，却没有打印出明显的业务错误。通常这不是 Scan 随机丢数据，而是某个 token 超过了 Scanner 当前允许的容量。先检查 scanner.Err()，再决定是否需要扩大上限。

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

处理长行的关键不是把缓冲区设得越大越好，而是在第一次调用 Scan 之前，用 Scanner.Buffer 给单个 token 设定一个符合业务和内存预算的最大容量；循环结束后必须检查 Err()，才能区分正常结束和容量不足。

先看 Scan 返回 false 到底发生了什么

Scan 返回 false 只有一个表面结果：当前没有可继续交付的 token。输入已经读完、底层 Reader 返回错误，以及 token 太大，都可能走到这个结果。因此只写 for scanner.Scan() {}，却不检查 Err，就会把长行错误伪装成正常 EOF。

package main

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

func readLines(input string) error {
    scanner := bufio.NewScanner(strings.NewReader(input))
    for scanner.Scan() {
        // 这里只处理已经成功切出的完整 token。
        fmt.Println(scanner.Text())
    }
    if err := scanner.Err(); err != nil {
        // Scan 提前停止时，把容量或底层读取错误返回给调用方。
        return fmt.Errorf("读取文本失败: %w", err)
    }
    return nil
}

func main() {
    // 通过重复字符构造一个明显长于普通示例的单行输入。
    input := strings.Repeat("x", 100000) + "\n"
    if err := readLines(input); err != nil {
        fmt.Println(err)
    }
}

这段代码的判断顺序很重要：先消费成功的 token，循环结束后再读 Err。如果错误是 token 超过限制，返回值通常会带有 bufio.Scanner: token too long 这一类信息；如果是 Reader 本身失败，也会保留底层错误。

默认容量为什么会让长行提前停止

Scanner 面向的是 token 流，不是一个没有边界的文本读取器。默认配置适合普通行、单词和小型分隔数据，但日志中的堆栈、压缩后的单行 JSON、批量编码字段等内容，可能把一个 token 拉得很长。一旦分割函数无法在允许的缓冲范围内交付 token，Scanner 就会停止继续扫描。

这里要区分两个概念：

• 初始缓冲区：Scanner 开始工作时可直接使用的空间，过小不代表最终一定失败。
• 最大容量：Scanner 为单个 token 扩容时不能突破的上限，真正决定长行是否能被接收。

所以增加 bufio.NewReaderSize 的大小，并不能自动解除 Scanner 的 token 限制；正在使用的对象是 Scanner，就应该配置它自己的 Buffer。

在第一次 Scan 之前设置 Scanner.Buffer

Scanner.Buffer 必须在第一次调用 Scan 之前使用。配置完成后，Scanner 可以在设定上限内逐步扩展缓冲区。下面的例子把单行上限设为 2 MiB：这个数字只是示例，生产代码应根据真实输入协议调整。

package main

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

func scanLargeLines(r io.Reader) error {
    const (
        initialBuffer = 64 * 1024       // 给常见行预留的初始空间。
        maxLineSize   = 2 * 1024 * 1024 // 限制单行最大容量，避免无限扩张。
    )

    scanner := bufio.NewScanner(r)
    // Buffer 必须放在第一次 Scan 之前，否则配置不会作用于已开始的扫描。
    scanner.Buffer(make([]byte, initialBuffer), maxLineSize)

    line := 0
    for scanner.Scan() {
        line++
        // 业务处理可以在这里完成，避免把所有行一次性读入内存。
        fmt.Printf("line=%d bytes=%d\n", line, len(scanner.Bytes()))
    }
    if err := scanner.Err(); err != nil {
        // 把 token 过大和底层 Reader 错误统一交给上层决定是否重试或拒绝。
        return fmt.Errorf("扫描第 %d 行失败: %w", line+1, err)
    }
    return nil
}

初始缓冲区不必直接等于最大容量。这样做可以让普通输入保持较小的起步成本，只有实际 token 变长时才向上扩展；同时，最大容量又构成一个明确的资源边界。

容量设置要和内存预算一起看

把 max 改成一个很大的数，确实可能让报错暂时消失，但也会削弱输入边界。若服务同时处理多个请求，多个超长 token 可能让内存压力成倍出现。更稳妥的做法是先回答三个问题：单行业务上允许多长、并发时最多有多少个 Scanner、超过上限后应该拒绝还是切换处理策略。

什么时候不该继续扩大 Scanner

如果输入长度没有可信上限，或者单行本身可能包含几十 MiB 甚至更大的数据，继续把 Scanner 的最大值调大往往不是最合适的修复。此时可以考虑 bufio.Reader，按照分隔符分段读取，或者使用能处理流式字段的解析器，把“大 token”拆成多个可控片段。

选择 Scanner 的理由通常是代码简单、分割函数清晰和普通 token 处理方便；选择 Reader 的理由则是需要掌控分段、保留超长数据的增量处理状态，或不希望把完整 token 放入单个缓冲区。两者不是谁更快的固定结论，而是输入边界不同。

发布前把这几个检查点补齐

1. 确认 Buffer 调用发生在第一次 Scan 之前。
2. 确认 max 的单位是字节，并与单个 token 的业务上限一致。
3. 确认循环结束后调用 scanner.Err()，不要只把 false 当作 EOF。
4. 确认超限输入有明确处理：拒绝、记录、分段读取或转交其他解析路径。
5. 确认并发请求数量与最大 token 容量相乘后仍在可接受的内存预算内。

一句话记忆：Scanner 负责把输入切成 token，Buffer 负责给单个 token 设上限，Err 负责告诉你为什么停止。只扩大容量而不检查错误，问题只是被推迟；只检查错误而没有合理上限，服务又可能失去资源边界。

相关问题

Scanner.Buffer 应该设置多大？

以业务允许的最大 token 长度为基础，再留出少量格式余量；如果无法给出可信上限，就不要用一个极大的固定值掩盖输入风险。

为什么设置了 NewReaderSize 还是报 token too long？

因为 Scanner 的 token 上限由 Scanner.Buffer 控制，Reader 的内部缓冲区大小不会替代 Scanner 的最大容量配置。

Scan 返回 false 就一定是 EOF 吗？

不是。循环后检查 Err()；返回 nil 才能说明没有记录到扫描错误，不能把 false 单独解释成正常结束。