Go Scanner 遇到超长日志返回 token too long 怎么办

用 bufio.NewScanner 逐行读日志时，如果某一行超过默认缓冲，循环会提前结束，随后 scanner.Err() 返回 bufio.Scanner: token too long。偶发的长行可以在第一次 Scan 前调用 Scanner.Buffer；如果日志行大小不可控，则应改用 bufio.Reader 分片读取。

为什么 Scanner 会在超长日志上报错

Scanner 默认使用 ScanLines，一个 token 通常就是一整行。标准库的 MaxScanTokenSize 是 64 * 1024，因此一行 JSON、堆栈或压缩字段只要超过这个范围，Scan 就会返回 false，错误要到 Err 才能看到。

这里有个容易漏掉的细节：扫描停止后并不会自动从超长行恢复。不要只看循环结束就当作正常 EOF，也不要在同一个 Scanner 上继续调用 Scan 期待它跳过坏行。

日志行大小可估计时，先调大 Scanner.Buffer

如果业务能给日志行设定上限，例如最大约 2 MiB，继续用 Scanner 会更简单。缓冲设置必须位于第一次 Scan 之前；初始缓冲可以小一些，第二个参数决定 Scanner 最多扩容到多少字节。

package main

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

func scanLog(r io.Reader) error {
    scanner := bufio.NewScanner(r)
    // 预留常见行大小，并把单行硬上限设为 2 MiB。
    scanner.Buffer(make([]byte, 64*1024), 2*1024*1024)
    for scanner.Scan() {
        // Text 会复制当前 token，适合交给不会长期持有的处理函数。
        fmt.Println(len(scanner.Text()))
    }
    // Scan=false 可能是 EOF，也可能是 token 太大或底层读取失败。
    return scanner.Err()
}

func main() {
    // 这里只构造输入示意；生产代码通常传入打开的日志文件。
    if err := scanLog(strings.NewReader("small line\n")); err != nil {
        fmt.Println("read log:", err)
    }
}

不要把第二个参数随手写成很大的数来“保证不报错”。它是单个 token 的内存上限，面对外部输入时应结合日志格式、并发量和进程内存预算设置；超过业务上限的行，最好明确记录并拒绝或转入异常处理。

单行大小不可控时，改用 Reader 分片读取

官方文档把 bufio.Reader 推荐给需要更大 token 或更细错误控制的程序。ReadLine 返回一段内容和 isPrefix 标记；标记为 true 时说明这一行还没结束。每次读取后立刻 append 到自己的切片，避免下一次读操作覆盖 Reader 的内部缓冲。

package main

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

func readLongLines(r io.Reader, handle func([]byte) error) error {
    reader := bufio.NewReaderSize(r, 64*1024)
    var line []byte
    for {
        fragment, isPrefix, err := reader.ReadLine()
        if err != nil {
            // 没有换行的最后一行会在前一次调用中返回；这里仅处理真正的结束。
            if errors.Is(err, io.EOF) {
                return nil
            }
            return err
        }
        // ReadLine 的片段只在下一次读取前有效，这里必须复制到自有切片。
        line = append(line, fragment...)
        if isPrefix {
            continue
        }
        if err := handle(line); err != nil {
            return err
        }
        // 复用容量，减少连续长行带来的重复分配。
        line = line[:0]
    }
}

func printLine(line []byte) error {
    // 这里按完整行处理，也可以改成流式解析 JSON 或字段。
    fmt.Println(len(line))
    return nil
}

这个方案仍然可能在业务处理阶段保留一整行，所以“分片读取”不等于“永远零内存增长”。如果连完整行都不应进入内存，就在拿到每个片段时直接做增量解析，并设计跨片段的状态机；如果只是不想受 Scanner 的固定 token 上限影响，以上写法已经足够。

上线前按行大小和内存预算选方案

排查时先确认错误来源：只有 scanner.Err() 明确是 token too long，才需要调整 token 策略；如果是文件权限、网络读取或自定义 SplitFunc 错误，盲目增大 Buffer 不会解决根因。另一个常见坑是保存 scanner.Bytes() 的切片后继续 Scan：它可能在下一次扫描时被覆盖，需要长期保存时复制一份。

常见问题

Scanner.Buffer 的 max 写成 2*1024*1024 就一定能读 2 MiB 吗？

不一定。token 还要容纳分隔符等额外字节，实际可用大小可能略小；把 max 当作安全上限，而不是精确的正文长度。

可以在 Scan 返回 false 后重新调用 Buffer 吗？

不建议。Buffer 必须在扫描开始前调用；扫描已经开始后调用会触发 panic。应在创建 Scanner 后立即完成配置。

为什么不直接把 Scanner 换成 ReadString？

ReadString 更直接，但同样会把分隔符前的数据组成一个字符串。若行长不可控，使用 ReadLine 的片段标记，或直接做增量解析，更容易设置内存上限。