Go bufio.Scanner 升级后行为变化怎么定位

Go 升级后，bufio.Scanner 的 token 数量、分行结果或结束状态突然不同，先别急着把原因归为“Scanner 改了”。更稳妥的定位顺序是：固定 Go 工具链和 GODEBUG，使用同一份输入字节，再比较 SplitFunc、token 缓冲上限和 scanner.Err()。这几层中任何一层变化，都可能让表面结果不同。

先固定升级前后的工具链和输入

第一步不是改 Buffer，而是把“旧环境”和“新环境”记录成可比较的样本。构建机器、GOTOOLCHAIN、模块中的 Go 版本、环境变量以及输入文件都可能不同。尤其是从管道、网络连接或并发生产者读取时，读取时序变化也会被误认为 Scanner 语义变化。

# 记录编译器与自动工具链，确认比较的不是两套不同环境。
go version
go env GOVERSION GOTOOLCHAIN GODEBUG

# 固定模块依赖和测试输入，避免升级时顺手换了数据源。
go env GOMOD
go list -m all

排查时建议准备一份小型 fixture，明确写出 LF、CRLF、单独 CR、空行、末尾没有换行和超过 64 KiB 的记录。比较时先打印输入的字节长度与十六进制摘要，不要只看终端里肉眼相同的文本。

核对 ScanLines 与自定义 SplitFunc 的边界

官方文档把默认分割函数定义为 ScanLines：它返回去掉行尾标记的文本，行尾是可选的回车加必需的换行，也就是 \r?\n。因此，只有 \r 的旧数据在升级前后出现分组差异时，应该先检查输入协议和自定义切分函数，而不是假定版本改变了默认规则。

自定义 SplitFunc 要重点看三个返回值：advance 是否真的推进输入，token 是否在完整记录出现时返回，以及 atEOF 时是否交付最后一段数据。返回 (0, nil, nil) 表示还需要更多数据；如果函数长期不推进输入，扫描器可能因为连续空 token 而 panic。

func scanAll(r io.Reader, split bufio.SplitFunc) ([]string, error) {
    // 每次调用都显式设置切分函数，避免依赖旧代码中的隐式默认值。
    scanner := bufio.NewScanner(r)
    if split != nil {
        scanner.Split(split)
    }

    var tokens []string
    for scanner.Scan() {
        // Text 会创建字符串，适合需要在下一次 Scan 后继续保存的结果。
        tokens = append(tokens, scanner.Text())
    }
    // false 可能是 EOF，也可能是读取错误或 token 超限。
    if err := scanner.Err(); err != nil {
        return nil, fmt.Errorf("扫描失败: %w", err)
    }
    return tokens, nil
}

把 token 上限、Bytes 生命周期单独验证

升级后最容易被忽略的是数据形态变化：同一字段在新版本业务中变长，或者输入从短行变成 JSON、堆栈和日志拼在一起。当前 bufio 文档说明，默认扫描使用 MaxScanTokenSize，值为 64 KiB；实际可容纳的 token 还要为行尾等额外字节留空间。

func scanLargeLines(r io.Reader, maxToken int) error {
    // Buffer 必须在第一次 Scan 前设置；maxToken 是单条记录的硬上限。
    scanner := bufio.NewScanner(r)
    scanner.Buffer(make([]byte, 32*1024), maxToken)

    for scanner.Scan() {
        // Bytes 不分配新数组，若要跨下一次 Scan 保存，必须自行复制。
        token := append([]byte(nil), scanner.Bytes()...)
        _ = token
    }
    // 把 token 超限和底层 Reader 错误统一交给调用方判断。
    return scanner.Err()
}

Buffer 不能在扫描开始后调用，否则会 panic；Bytes 返回的底层数组可能在下一次 Scan 时被覆盖。如果升级后出现“上一条 token 被改写”，看的是保存方式，不是分行算法。

用 Err 和官方兼容资料收敛结论

Scan 返回 false 时，既可能正常到达 EOF，也可能发生读取错误。只有 Err 返回 nil，才可以把这次停止当成正常结束。把 Err 记录下来后，再去对照对应 Go 版本的 release notes；不要用一次“升级前能跑、升级后失败”替代最小复现。

Go 的兼容性文档说明，部分为了修复错误或引入新行为的变化会提供 GODEBUG 兼容开关，但不是每个变化都有开关。若官方资料明确给出开关，才把它当作临时迁移手段；否则应修正输入契约、SplitFunc、Buffer 或错误处理。

常见问题

升级 Go 后 Scanner 会自动改变默认分行规则吗？

不能这样推断。先确认实际使用的 Go 版本和输入字节；默认 ScanLines 的边界仍是可选 CR 加必需 LF。

Scan 返回 false 就表示读取完成了吗？

不表示。循环后调用 scanner.Err()，只有返回 nil 才能排除非 EOF 错误。

调大 Buffer 就能解决所有升级后差异吗？

不能。它只处理 token 缓冲上限；换行、SplitFunc、Bytes 复用和底层 Reader 错误仍要分别检查。