Go Scanner.Buffer 怎么设置最大 token 而不浪费大块内存

Go 的 bufio.Scanner 适合逐行或按分隔符读取文本，但它有一个容易被忽略的边界：默认 token 缓冲上限是 64 KiB 左右，超过上限时扫描会停止并返回 token too long。解决办法不是直接把 max 写成几百 MB，而是先估算业务中单条 token 的合理上限，再用一个较小的初始缓冲区配合可解释的最大值。

先分清初始缓冲区和 max 上限

官方文档把 Scanner.Buffer(buf, max) 定义为：为 Scanner 提供一个初始缓冲区，并设置扫描 token 时可使用的最大缓冲区大小。若 token 装不进这个上限，扫描会不可恢复地停止。对默认的 ScanLines 来说，max 不只要容纳正文，还要给换行等边界字节留下空间。

因此，下面两种写法含义不同：make([]byte, 32*1024) 表示先给 32 KiB 的缓冲；256*1024 表示最多允许 Scanner 将 token 缓冲扩大到 256 KiB。它们都应在第一次调用 Scan 前设置。

按 token 分布估算一个不浪费的 max

实际项目可以从日志、导入文件或接口请求中统计单条记录长度。一个好用的计算思路是：max = 业务允许的最大正文长度 + 分隔符余量 + 安全余量。如果绝大多数行小于 8 KiB，偶尔出现 40 KiB 的行，就可以把初始缓冲放在 8 或 16 KiB，把 max 设为 64 或 128 KiB，而不是一上来分配 32 MiB。

用 Scanner.Buffer 写受控读取代码

下面示例把常态行大小和异常长行上限分开表达。示例没有把扫描器当成无限容量的文件解析器，而是把超过 256 KiB 的单行视为输入边界错误，并在循环结束后统一检查 Err。

package main

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

func main() {
	input := strings.NewReader("短行\n" + strings.Repeat("x", 100000) + "\n")
	scanner := bufio.NewScanner(input)
	// 初始缓冲覆盖常态行，max 覆盖允许的最长行并留出换行余量。
	scanner.Buffer(make([]byte, 16*1024), 256*1024)

	for scanner.Scan() {
		// Text 返回当前 token；这里示范读取，不把 token 长期保存。
		fmt.Println(len(scanner.Text()))
	}
	if err := scanner.Err(); err != nil {
		// 超过 max 或底层 Reader 出错，都必须在这里处理。
		fmt.Printf("scan failed: %v\n", err)
	}
}

关键点是 Buffer 的调用时机和 Err 的检查。扫描完成并不自动等于成功：EOF 会让 Err 返回 nil，但底层读取错误或 token 超限会通过它暴露。若使用 Bytes 而不是 Text，还要注意返回切片只适合在下一次扫描前使用。

token too long 与内存边界怎么处理

当输入超过 max，继续增大 max 只是改变故障出现的位置。更稳妥的做法是把上限和业务约束绑在一起：日志行、配置行可以拒绝异常长度；JSON、压缩内容或用户可提交字段则应在更早的输入层限制大小。并发创建大量 Scanner 时，过大的初始 buf 会把常态内存成本直接乘上并发数。

还要区分“允许的最大 token”和“期望的平均 token”。初始缓冲按常态大小设置，max 按硬边界设置，能让大多数请求保持较低内存，同时让异常输入有确定的失败方式。不要把 max 设为小于初始缓冲容量，也不要为了消除错误而删除 Err 判断。

长度不可控时什么时候改用 bufio.Reader

Scanner 的优势是 SplitFunc 简洁、逐 token 处理方便；代价是 token 太大时扫描不可恢复，而且 Reader 可能已经向前读取了一部分。官方文档也建议：需要更强的错误控制、处理大 token，或必须在同一个 Reader 上进行连续扫描时，考虑 bufio.Reader。

如果业务能够给出单条记录的硬上限，Scanner.Buffer 是清晰的方案；如果记录大小几乎没有上限，或者需要保留超长行的前半段并继续读完，应改用 ReadString、ReadBytes 或 ReadLine 组合自己的分段策略。选择的标准不是“哪个 API 更快”，而是是否能对输入长度和失败后的恢复方式负责。

常见问题

max 设置成 1 MB 会马上占用 1 MB 内存吗？

不应把 max 理解为必然的立即分配量。它是 Scanner 为 token 增长所允许使用的上限，初始缓冲容量和实际 token 大小同样影响常态占用；但设置很大的上限仍会放宽单个 Scanner 的内存边界。

为什么设置了 Buffer 仍然出现 token too long？

通常是实际 token 超过了 max，或者 max 没有在第一次 Scan 前设置。对 ScanLines，还要把换行等边界字节纳入估算。

可以把 max 设置成 math.MaxInt 吗？

技术上放宽上限不等于输入安全。这样会让异常或恶意超长 token 把内存压力推迟到更危险的位置，生产代码应使用业务可解释的硬限制。

Scanner 能不能读取任意大的文件？

文件总大小不是关键，单个 token 的大小才是 Scanner 的直接边界。只要每行或每个 token 受控，Scanner 可以逐段处理大文件；单条记录不可控时应考虑 Reader。

设置 Scanner.Buffer 的核心不是寻找一个“足够大”的数字，而是把常态缓冲、最大 token、分隔符余量和失败策略分别说清楚。这样既能消除默认 64 KiB 上限带来的误报，也能避免用超大缓冲掩盖输入边界问题。