Go Scanner 怎样读取超长日志行

用 bufio.Scanner 逐行读日志很方便，但它有一个容易被忽略的边界：默认 token 缓冲上限是 64 KiB 左右，超长日志行会让 Scan() 停止。处理方法通常有两种：如果仍然希望“一次得到一行”，就在第一次调用 Scan 之前用 Buffer 提高上限；如果行长度不可控、还要细致处理部分数据，则改用 bufio.Reader。

下面按“输入数据—扫描配置—错误边界—读取选择”的顺序整理，示例只依赖 Go 标准库。官方文档地址：https://pkg.go.dev/bufio

默认 Scanner 为什么读不了超长行

Scanner 默认使用 ScanLines 把输入切成行，同时把单个 token 的最大缓冲设置为 MaxScanTokenSize，当前值是 64 * 1024。这里的上限不是“文件最多只能读 64 KiB”，而是“某一个待返回的 token 不能超过 Scanner 能容纳的范围”。一旦单行超过这个范围，循环会提前结束，真正原因要从 scanner.Err() 读取。

package main

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

func main() {
	// 这里故意构造一行较长的文本，观察 Scanner 的错误边界。
	input := strings.NewReader(strings.Repeat("x", 70*1024) + "\n")
	scanner := bufio.NewScanner(input)

	for scanner.Scan() {
		// Text 返回当前行；循环可能因为 token 过大而提前结束。
		fmt.Println(len(scanner.Text()))
	}
	if err := scanner.Err(); err != nil {
		// 不要只看 Scan 返回 false，要把具体读入错误输出出来。
		fmt.Println("读取失败:", err)
	}
}

这个现象与输入文件大小无关：许多普通短行可以先被读出来，只有遇到无法放进当前缓冲的那一行时才停止。因此排查日志读取问题时，先看 Err()，不要把“循环结束”直接当成正常 EOF。

在第一次 Scan 前调大 Buffer

如果日志行的长度上限是可以估计的，最小改法是在创建 Scanner 后、第一次调用 Scan 前调用 Buffer。第二个参数是允许分配的最大缓冲容量；第一个参数是可复用的初始缓冲。它们都不是必须精确等于一行长度，关键是最大值要覆盖业务允许的最长 token，并给换行等分隔字节留出余量。

package main

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

func main() {
	input := strings.NewReader(strings.Repeat("log=ok ", 20*1024) + "\nshort line\n")
	scanner := bufio.NewScanner(input)

	// 初始缓冲用于减少小行读取时的分配；最大值覆盖预期的长日志行。
	initial := make([]byte, 32*1024)
	scanner.Buffer(initial, 2*1024*1024)

	for scanner.Scan() {
		// Text 只在当前迭代内使用，避免把 Scanner 的内部切片长期保存。
		fmt.Printf("line bytes=%d\n", len(scanner.Bytes()))
	}
	if err := scanner.Err(); err != nil {
		// 超过 2 MiB 或底层读取失败时，统一返回错误。
		fmt.Println("读取失败:", err)
	}
}

Buffer 必须在扫描开始前设置；在第一次 Scan 之后再调用会触发 panic。设置 2 MiB 也不代表每次都立即分配 2 MiB，Scanner 会按需要扩展，但这个上限会成为单 token 的内存边界。

max 参数怎样选才不会留下新的边界问题

可以按日志协议的最大记录大小来定，而不是随手写一个特别大的数字。比如应用日志限制为 512 KiB，就可以把 max 设为 1 MiB，并在文档中注明这个约束。若日志内容来自外部系统且长度没有可靠上限，则应把“超长行”视为可预期输入，记录上下文后转用 Reader 或明确拒绝该条记录。

另外，scanner.Bytes() 返回的切片可能复用内部数组，下一次 Scan 后内容可能被覆盖。如果要异步处理或跨循环保存，应该复制一份；只在当前循环内解析则可以直接使用。

什么时候应该换成 bufio.Reader

Scanner 适合 token 边界清晰、每行大小可控的日志。它遇到超大 token 时会不可恢复地停止，而且底层 reader 可能已经向前读取了一部分数据。对于需要继续读取、需要处理超长行的片段、或必须区分“读到分隔符”和“缓冲已满”的场景，bufio.Reader 更合适。

package main

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

func main() {
	reader := bufio.NewReaderSize(strings.NewReader("part-a-"+strings.Repeat("x", 70*1024)+"\npart-b\n"), 32*1024)

	for {
		// ReadString 遇到换行返回；行太长时仍能得到分段和非 nil 错误信息。
		part, err := reader.ReadString('\n')
		fmt.Printf("part bytes=%d\n", len(part))
		if err != nil {
			// EOF 表示没有更多数据，其他错误需要交给调用方处理。
			if err != io.EOF {
				fmt.Println("读取失败:", err)
			}
			break
		}
	}
}

这里的重点不是把 Reader 当成更大的 Scanner，而是换取更细的控制：读取结果可以按片段处理，调用方可以决定是否拼接、截断、落盘或拒绝。若只需要一个完整字符串，也要为拼接后的最大长度设定业务限制，避免把无限长输入全部积压在内存中。

一张表记住选择边界

常见问题

把 max 调得越大越好吗？

不是。它扩大了单个 token 的可用上限，也扩大了异常输入可能占用的内存。应以日志协议的明确上限为依据，并在超限时记录和处理错误。

调用 Buffer 后还要改 Split 吗？

如果仍然按行读取，不需要，Scanner 默认就是 ScanLines。只有 token 边界不是换行时，才在首次 Scan 前设置自定义 SplitFunc。

Scanner 读完后怎么判断是 EOF？

循环结束后调用 Err()。返回 nil 才表示正常读到输入末尾；非 nil 说明有底层 I/O 错误或 token 超过缓冲上限。

总结

Go Scanner 读取超长日志行的第一选择是：在第一次 Scan 前设置 Buffer，并始终检查 Err()。如果最长行无法约束，或者需要继续消费超长 token 的片段，则换用 bufio.Reader。把“逐行便利性”和“输入长度边界”同时写进设计，才不会用一个过大的常数掩盖新的内存问题。