Go bufio.SplitFunc 为什么会触发 too many empty tokens

这个 panic 的根因通常不在 Scanner 缓冲区，而在自定义 SplitFunc 把同一段输入重复交付了。尤其是 atEOF=true 时，如果函数反复返回非 nil 的 token，同时 advance=0，Scanner 会发现输入位置没有变化，只能累计“空进展”次数，最终触发 bufio.Scan: too many empty tokens without progressing。

先看懂 Scanner 如何判定没有进展

SplitFunc 的四个判断量要一起看：输入切片是当前尚未处理的数据，atEOF 表示底层 Reader 已经没有更多数据，advance 是要消费的字节数，token 是要交给调用方的结果。最容易混淆的是：返回空字符串并不等同于返回 nil。

在没有完整 token 时，合法的等待状态是 0, nil, nil。Scanner 会保留当前位置并尝试读取更多数据。相反，0, []byte{}, nil 表示交付了一个非 nil 的空 token；如果此时又处于 EOF，当前位置不会移动，Scanner 就会把它记入 empties。

定位 EOF 分支里的空 token 循环

典型错误是把“没有分隔符”统一处理成空 token：

func badSplit(data []byte, atEOF bool) (int, []byte, error) {
	// 没有分隔符时错误地交付空切片，且没有消费输入。
	if bytes.IndexByte(data, ',') 

当 Reader 已经到 EOF，data 又没有变化，这个函数会持续返回同一个非 nil 空切片。Scanner 的保护阈值是内部常量控制的连续次数，源码中的判断是“超过 100 次”就 panic。它不是在说输入里有 100 个空字段，而是在说 SplitFunc 连续 100 多次没有让输入位置前进。

排查时先打印或记录这四项，而不是先调大 Scanner.Buffer：len(data)、atEOF、advance、token == nil。如果最后三项长期呈现 true, 0, false，根因已经很明确。

修正 SplitFunc 的三个返回分支

一个可靠的分隔函数通常只有三类出口：分隔符尚未到达且还可以读，返回 (0, nil, nil)；找到完整 token，返回消费分隔符后的字节数；EOF 下仍有尾部数据，则一次性消费尾部。若协议要求保留最后一个空字段，可以在明确结束时返回 ErrFinalToken，不要靠重复返回空 token 来表达结束。

func commaSplit(data []byte, atEOF bool) (advance int, token []byte, err error) {
	// 找到逗号时，连同逗号一起消费，避免下一次仍看到同一字节。
	if i := bytes.IndexByte(data, ','); i >= 0 {
		return i + 1, data[:i], nil
	}
	// 非 EOF 说明 token 可能被截断，交给 Scanner 继续读取。
	if !atEOF {
		return 0, nil, nil
	}
	// EOF 下保留最后一段；空尾字段用 ErrFinalToken 只交付一次。
	if len(data) == 0 {
		return 0, []byte{}, bufio.ErrFinalToken
	}
	return len(data), data, bufio.ErrFinalToken
}

这里的关键不是“任何时候都要 advance>0”，而是每个非 nil token 都要有清晰的结束语义。普通 token 用字节推进；最终空 token 用 ErrFinalToken 告诉 Scanner 不再回到这个分支。若业务不需要区分尾部空字段，也可以在 EOF 且 len(data)==0 时直接返回 0, nil, nil，让扫描自然结束。

用小型检查清单验证自定义分隔器

• 输入没有分隔符且未 EOF：是否返回 0, nil, nil，而不是空切片？
• 找到分隔符：advance 是否至少越过分隔符，下一次不会重复看见同一段数据？
• 输入以分隔符结尾：是否明确决定保留还是丢弃最后空字段？保留时是否只交付一次？
• 空输入：是否能在 EOF 下返回 nil token 或一次性的 ErrFinalToken？
• 超大 token 或需要继续处理错误：是否已经超出 Scanner 的简单边界？

不要用调大缓冲区来掩盖这个 panic。Buffer 只影响 token 能容纳多大，并不会改变 SplitFunc 的推进契约；如果 advance 始终为零，容量再大也没有意义。

什么时候应该改用 bufio.Reader

Scanner 适合“按 token 顺序读取，遇到错误就停止”的场景。官方文档也提醒，扫描停止后底层 Reader 可能已经向前读取了一段数据。若协议需要精确控制回退、恢复某类解析错误、处理明显超过默认 token 上限的内容，或要在同一个 Reader 上连续执行多种扫描，bufio.Reader 往往更合适。

相关问题

为什么 token=[]byte{} 和 token=nil 不一样？

前者是一个真实的空 token，后者表示当前没有 token。Scanner 会把它们当成不同信号处理，EOF 下反复交付前者就可能触发空 token 保护。

把 advance 改成 1 就一定正确吗？

不一定。只有确认当前数据至少有一个字节，并且跳过这一个字节不会破坏协议边界时才可以推进；否则应返回 nil token 请求更多数据，或返回明确错误。

Scanner.Err() 能捕获这个 panic 吗？

不能把它当普通扫描错误处理。这个条件由 Scan 直接 panic，应该先修正 SplitFunc 的返回契约；Err 更适合读取普通 I/O 或 SplitFunc 返回的错误。