登录
推荐 文章 Go 技术 课程 下载 专题 AI
首页 >  Golang >  Go问答

Go bufio.Scanner只返回前一部分内容的上限排查

来源:17golang原创

时间:2026-09-20 12:14:41 499浏览 收藏

Go 里用 bufio.Scanner 按行读取日志,前面的短行正常,遇到一条很长的 JSON 或堆栈信息后,后面的内容就像“只返回前一部分”。先不要截取字符串补救:很多时候是 Scan() 已经停止,而代码没有检查 scanner.Err()。如果单个 token 确实超过默认上限,应在第一次调用 Scan() 前设置 Buffer;如果输入可能大到无法设置合理上限,则换用 bufio.Reader

要点速览
  • Scanner 的限制针对单个 token,不是整个文件大小;默认最大缓冲约为 64 KiB,换行等分隔内容也可能占用空间。
  • Buffer 必须在第一次 Scan() 前调用,第二个参数是硬上限,单位是字节。
  • 每次扫描结束都要检查 Err();超大 token、底层读取错误和业务提前停止不能混为一谈。

先确认是不是 Scanner 提前停止

Scan() 返回 false 时,可能是正常到达 EOF,也可能是 token 太大或底层 Reader 报错。只读取 Text() 并不能判断原因。把错误检查放在循环之后,先把“读到一半”变成可以定位的结果:

package main

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

func readLines(input string) error {
    scanner := bufio.NewScanner(strings.NewReader(input))
    for scanner.Scan() {
        // 每次 Scan 成功才读取当前 token,避免使用失效的中间状态。
        fmt.Println(scanner.Text())
    }
    // false 既可能是 EOF,也可能是 token 太大或底层读取失败。
    if err := scanner.Err(); err != nil {
        return fmt.Errorf("扫描输入失败: %w", err)
    }
    return nil
}

如果长行之后循环结束,并且 Err() 返回类似 bufio.Scanner: token too long 的错误,根因就是单个 token 超出可用缓冲。没有错误则优先检查调用方是否在循环中主动 break,或是否把一条记录误当成了多条输入。

Go bufio.Scanner 从输入流到 Scan、Err 的长 token 错误边界说明图
图1:Scanner 的停止路径说明图,展示 Scan、token 缓冲和 Err 之间的关系;这是静态说明图,不是运行截图。

在第一次 Scan 前提高单个 token 上限

对“绝大多数行不长,偶尔有一条几百 KiB”的日志,仍然可以使用 Scanner。关键是提前设置一个符合业务边界的最大值,而不是无限制地把缓冲调大:

package main

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

func scanLargeLines(r io.Reader) error {
    scanner := bufio.NewScanner(r)
    // 初始缓冲服务于常见行;最大值限制单行内存,单位是字节。
    scanner.Buffer(make([]byte, 64*1024), 2*1024*1024)

    for scanner.Scan() {
        line := scanner.Bytes()
        // 当前 token 只在下一次 Scan 前使用,需长期保存时应复制它。
        fmt.Printf("收到 %d 字节\n", len(line))
    }
    // 上限之外的行会让扫描停止,不能把部分 token 当成完整记录。
    if err := scanner.Err(); err != nil {
        return fmt.Errorf("读取长行失败: %w", err)
    }
    return nil
}

Buffer 的第二个参数是单个 token 的最大字节数,不是“先读多少字节”。设置为 2 MiB 后,超过这个值的单行仍会失败;初始缓冲写成 64 KiB 也不会把每一行都预分配成 2 MiB。这个组合通常比盲目使用超大初始切片更稳妥。

用字节边界而不是字符感觉来定 max

Scanner 的缓冲和 len 都以字节计。中文、Emoji 或混合编码文本的字符数与字节数并不相同,配置上限时应以输入协议中的最大字节长度为准。如果一行最多允许 512 KiB,就把上限写成 512*1024,并为分隔符和解析后的结构预留合理余量。

现象先看什么处理方式
扫描在长行处停止scanner.Err()提高 Buffer 的 max,或拒绝超限记录
只有多字节文本更容易失败输入的字节数而非字符数按协议字节上限配置,不按字符数猜测
单行可能极大且不能设硬上限是否需要分片处理改用 bufio.ReaderReadStringReadBytesReadLine

还要注意,默认的 ScanLines 会去除行尾换行,并且最后一行即使没有换行也会返回。因而“没有末尾换行”不是长内容只返回一部分的充分证据。

Go 长行读取中 Scanner Buffer 与 bufio.Reader 选择边界结构图
图2:长行读取的选择结构图,比较 Scanner.Buffer 的硬上限与 Reader 分片读取;这是静态结构说明图。

超大记录改用 Reader,避免把内存上限伪装成修复

官方文档明确提示,Scanner 在 token 太大时会不可恢复地停止;需要更强错误控制或处理大 token 时,应考虑 bufio.Reader。例如用 ReadString('\n') 可以得到一整行和错误,但要考虑超大行会形成较大的字符串;用 ReadLine 则可以按片段接收,并根据 isPrefix 逐步拼接。

生产代码的选择可以按这个顺序:有清晰单行上限就用 Scanner 加 Buffer;输入大小不可控但可以拒绝超限记录,就保留 max 并记录指标;必须处理任意长记录,就用 Reader 分片,同时限制累计内存、记录长度和取消条件。不要只删除 Err() 检查,否则失败会被误报为“文件读完”。

常见问题

Buffer 应该在循环里调用吗?

不应该。它应在第一次 Scan() 之前调用;扫描开始后再改缓冲不会修复已经开始的读取过程。

把 max 设置成文件大小就一定安全吗?

不一定。文件大小只是总量,Scanner 约束的是单个 token。更合理的做法是依据协议限制单行,并配合拒绝、指标和资源预算。

Scanner.Bytes() 返回的内容能长期保存吗?

不能直接依赖。下一次扫描可能复用缓冲;需要异步处理或跨循环保存时,复制这段字节,或者使用 scanner.Text() 形成独立字符串。

排查这类问题的最短路径是:先看 Scan() 是否结束,再看 Err(),然后按单个 token 的字节边界选择 BufferReader。这样既能恢复合理长度的日志行,也不会用无限增大的缓冲掩盖输入协议问题。

声明:本文转载于:17golang原创 如有侵犯,请联系study_golang@163.com删除
相关阅读
更多>
最新阅读
更多>
课程推荐
更多>