Go bufio.Scanner 兼容单独 CR 换行的 SplitFunc 方案

如果输入文本只使用 \n 或常见的 \r\n，bufio.Scanner 默认的 bufio.ScanLines 通常就够用。但有些旧日志、跨平台导出文件或拼接文本会混用三种行尾：LF、CRLF，以及单独的 CR。

这时可以给 Scanner 换一个自定义 SplitFunc：优先处理 CRLF，再处理 LF，最后把不跟随 LF 的 CR 当作独立行结束符。关键是遇到位于缓冲区最后的 CR 时不能急着返回，要等下一批数据确认它是不是 CRLF。

默认 ScanLines 为什么漏掉单独 CR

Scanner 的默认拆分函数是 ScanLines。它以换行字节 \n 作为主要分隔点；如果分隔点前面紧挨着一个 \r，会把这个回车一起从 token 尾部去掉。因此，\r\n 会被当作一个完整的 Windows 行尾。

但单独的 \r 后面没有 \n，它不会触发默认的换行判断。比如输入 甲\r乙\n，默认函数可能把 甲\r乙 作为一行交给调用方，而不是得到两行。这个行为并不是 Scanner 读取失败，而是默认的分隔规则没有覆盖你的数据格式。

另外，SplitFunc 不只是返回 token，它还要返回已经消费的字节数 advance 和错误值。返回 (0, nil, nil) 表示当前数据还不足以组成一个完整 token，Scanner 应该继续读取；因此，判断缓冲区边界和 atEOF 是实现的重点。

按 CRLF、LF、CR 的顺序设计 SplitFunc

实现时先扫描当前缓冲区，遇到 \n 时再回看前一个字节是否为 \r。这样可以把 CRLF 一次性消费掉，并从 token 中去掉 CR。遇到 \r 时，如果下一个字节不是 \n，就可以把它视为单独行尾；如果它已经位于缓冲区末尾，则暂时等待下一批数据。

package main

import "bufio"

// scanMixedLines 同时接受 LF、CRLF 和单独 CR 三种行尾。
func scanMixedLines(data []byte, atEOF bool) (advance int, token []byte, err error) {
	for i, b := range data {
		switch b {
		case '\n':
			// LF 前面的 CR 属于 CRLF，不能把它留在当前 token 中。
			end := i
			if i > 0 && data[i-1] == '\r' {
				end = i - 1
			}
			return i + 1, data[:end], nil

		case '\r':
			if i+1 

这里有两个容易写错的点。第一，CRLF 分支不能在看到 CR 时立即返回，否则下一次又会处理 LF，可能产生空 token 或多推进一次。第二，advance 必须覆盖已经消费的分隔符，返回的 token 则只保留行内容。

处理缓冲区末尾与 atEOF

Scanner 会分批把数据交给 SplitFunc。假设第一批数据正好以 \r 结尾，此时无法知道下一批开头是不是 \n。如果立刻把它判为单独 CR，跨缓冲区的 CRLF 就会被错误拆开。

因此，代码在 CR 位于当前数据最后一个字节且 atEOF=false 时返回 (0, nil, nil)。Scanner 会保留未处理数据并继续读入。只有当 atEOF=true，才能确定这个末尾 CR 不会再接上 LF，可以安全地结束当前行。

同理，文件结尾没有换行符时，atEOF=true 且 data 仍有内容，应该返回这段剩余文本作为最后一个 token。只有 atEOF=true 且没有剩余字节时，才返回空结果结束扫描。

接入 Scanner 并检查 Err

定义好拆分函数后，用 Scanner.Split 替换默认规则即可。示例输入故意混合三种行尾，并在循环后检查 Err，这样底层 Reader 的错误不会被误认为正常结束。

package main

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

func main() {
	// 输入同时包含单独 CR、LF、CRLF，以及没有终止符的最后一行。
	input := "甲\r乙\n丙\r\n丁"
	scanner := bufio.NewScanner(strings.NewReader(input))
	scanner.Split(scanMixedLines)

	for scanner.Scan() {
		// Text 会把当前 token 转成字符串，适合本例的短文本输出。
		fmt.Printf("行：%s\n", scanner.Text())
	}

	if err := scanner.Err(); err != nil {
		// Scan 返回 false 既可能是 EOF，也可能是底层读取错误。
		fmt.Printf("扫描失败：%v\n", err)
	}
}

预期的行内容是 甲、乙、丙、丁。这里的输出是代码逻辑的示例结果，不代表图片中的内容是终端截图；文章配图只是帮助理解拆分关系的静态说明图。

长行和复用场景要单独处理

自定义 SplitFunc 只解决分隔符问题，不会改变 Scanner 的 token 大小限制。默认缓冲上限适合普通文本，如果单行可能很长，需要在第一次调用 Scan 前设置更大的缓冲区：

// 为可能超过默认上限的单行设置初始缓冲区和最大 token 大小。
scanner.Buffer(make([]byte, 32*1024), 1024*1024)
scanner.Split(scanMixedLines)

如果输入可能出现不可控长度的单行，或者需要更细的读取错误、重试、回退和顺序扫描控制，应该考虑 bufio.Reader。Scanner 的优势是把常见的 token 循环写得简洁；它并不适合所有需要精确掌握 Reader 状态的场景。

常见误区总结

结语

这类问题的核心不是把 ScanLines 改成更复杂的字符串替换，而是正确实现 SplitFunc 的三件事：识别行尾、返回准确的推进字节数、在数据不足时尊重 atEOF。按 CRLF、LF、单独 CR 的顺序判断，再覆盖无终止符的最后一行，就能稳定读取混合格式文本。

如果你的数据只有 LF 或 CRLF，继续使用默认 bufio.ScanLines 更简单；只有在输入格式确实包含单独 CR，或你需要自定义 token 边界时，才值得引入这个 SplitFunc。

相关问题

• SplitFunc 为什么要返回 (0, nil, nil)？因为当前缓冲区还没有完整 token，Scanner 需要保留数据并继续读取。
• CRLF 会不会被拆成两行？只要先识别 LF 并回看前一个 CR，再一次性推进到 LF 后面，就不会拆开。
• 没有换行符的最后一行怎么办？在 atEOF=true 且 data 非空时返回剩余数据。
• Scanner 报 token too long 怎么办？先用 Scanner.Buffer 提高上限；如果长度不可控，再评估 bufio.Reader。

官方参考：https://pkg.go.dev/bufio#ScanLines、https://go.dev/src/bufio/scan.go