Go bufio.Scanner 结果不稳定怎么办

Go bufio.Scanner 的结果看起来不稳定时，先检查三件事：是否把 Bytes() 返回的临时切片留到了下一次扫描之后，是否在循环结束后处理 Err()，以及是否让多个 goroutine 共同读取或修改扫描数据。保存文本可用 Text()；保存字节则要在下一次 Scan 前复制。条数和顺序问题还要检查分词规则与异步输出。

官方地址：https://pkg.go.dev/bufio#Scanner

从串行导入改成异步处理，变化发生在哪里

设想一个逐行导入工具：最初每读一行就立即处理，后来为了并行计算，把一批字节切片留到循环外，偶尔发现前面的记录内容变了。另一个分支只在大文件里少读几行，于是两类问题都被叫作“Scanner 不稳定”。这个场景用于分析设计取舍，不代表本文记录了一次实际事故。

值得关注的工程方向，是从“循环里立刻消费”转向“先交接、后处理”时，必须明确数据所有权。这里没有搜索量或行业采用率来证明它是流行趋势；能确定的是交接点越多，临时缓冲、持久记录和结果顺序越需要分别约定。先把现象归类，再决定改哪一层。

临时字节与持久记录要有清楚边界

Scanner.Bytes() 返回最近一次扫描结果的视图，底层数组可能被后续 Scan 改写。把这个切片 append 到另一个切片，只复制切片描述信息，并不因此获得独立的数据。它可以用于当前迭代中立即完成的读取，但不适合未经复制就放进缓存、异步任务或长期记录集。

如果下游要文本，保存 Text 得到的字符串；如果下游需要可修改字节，使用独立副本，例如 bytes.Clone。复制解决生命周期问题，不会让多个消费者同时修改同一份副本自动变安全。业务若必须共享可变状态，仍要规定同步方式。

字节复制文档：https://pkg.go.dev/bytes#Clone

扫描者和消费者各自负责什么

单一扫描者负责推进输入、定义记录边界和记录扫描错误；消费者负责处理已经交接的稳定记录。文件导入、日志解析和批量文本分析都可以采用这个分工，但并非所有项目都需要并发。先保持串行，往往更容易判断内容是否正确。

需要并发时，可把输入序号与稳定字符串一同交接，最终按序号汇总。channel 传递字节切片并不会自动复制底层数组；即便发送成功，扫描者继续复用那片内存，接收者也可能还在读取。不要把“传过 channel”当成拥有独立数据的证明。

并发同步依据：https://go.dev/ref/mem

同一份输入还应只由约定的读取者消费。两个 Scanner 共用同一个 Reader，并不等于各自获得完整输入副本。若需要重复读取，应提供独立且内容一致的输入来源；这与增加缓冲大小是两件不同的事。

缓冲限制、空行与半批成功的代价

Scan 返回 false 既可能是正常结束，也可能是错误；循环外必须读 Err。增加缓冲应在扫描开始之前完成，但容量限制并不等于业务行长限制，更不等于整批内存预算。不能为了暂时避免报错就无限扩大限制。

默认 ScanLines 会去除行结束标记，允许空行，并保留没有末尾换行的最后一条非空行。业务若再做 TrimSpace、跳过空串或换成 ScanWords，记录数可能变化；那是规则变化，应写进导入约定。要求逐字节保留原始换行时，默认逐行扫描也不是合适的格式保留方案。

失败策略同样影响“稳定”的含义。边读边写数据库时，后面的长行失败不会撤销前面已提交的数据；若调用方需要整批结果，可以先收集并在失败时返回空结果。本例选择后者，代价是持有整批文本，因此额外设置行数和累计文本限制。

先采用有界串行读取，再决定是否并发

下面示例只使用一个 Scanner，保留字符串快照、输入序号和错误链。单行限制为 16 KiB，最多 10000 行，累计文本不超过 8 MiB；这些是示例的业务约定。代码未在本文生成过程中执行，后面的结果解释来自固定输入和规则推导。

package main

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

type Row struct {
    Line int
    Text string
}

// readRows 采用整批返回策略，任何输入失败都不交付部分结果。
func readRows(r io.Reader) ([]Row, error) {
    const maxLine = 16 * 1024
    const maxRows = 10000
    const maxText = 8 * 1024 * 1024
    s := bufio.NewScanner(r)
    // 扫描缓冲上限留出余量；业务行长另行检查，且配置必须早于 Scan。
    s.Buffer(make([]byte, 32*1024), 256*1024)
    rows := make([]Row, 0)
    total := 0
    for s.Scan() {
        line := len(rows) + 1
        if line > maxRows {
            return nil, fmt.Errorf("记录超过 %d 行", maxRows)
        }
        n := len(s.Bytes())
        if n > maxLine {
            return nil, fmt.Errorf("第 %d 行超过 %d 字节", line, maxLine)
        }
        if n > maxText-total {
            return nil, fmt.Errorf("文本累计超过 %d 字节", maxText)
        }
        total += n
        // 保存字符串快照，绝不把 Scanner.Bytes 的临时视图放入结果集。
        rows = append(rows, Row{Line: line, Text: s.Text()})
    }
    if err := s.Err(); err != nil {
        return nil, fmt.Errorf("扫描在 %d 条完整记录后失败: %w",
            len(rows), err)
    }
    return rows, nil
}

func run() error {
    // 混合 CRLF、空行与无末尾换行的固定输入，便于解释记录边界。
    rows, err := readRows(strings.NewReader("cedar\r\n\nmaple\ncedar"))
    if err != nil {
        return err
    }
    for _, row := range rows {
        if _, err := fmt.Printf("%d:%q\n", row.Line, row.Text); err != nil {
            return fmt.Errorf("输出失败: %w", err)
        }
    }
    return nil
}

func main() {
    if err := run(); err != nil {
        fmt.Fprintln(os.Stderr, err)
        os.Exit(1)
    }
}

累计文本限制统计的是去除行结束标记后的 token 字节，不包含切片、字符串描述信息和分配器开销，也不代表真实内存上限。极长一行可能先触发扫描缓冲限制，拿不到完整 token，此时由 Err 返回扫描失败，不能保证每种超长输入都得到相同的业务错误文字。

代码中的 Reader 由调用方提供并管理。若换成打开的文件，应在打开它的调用层安排关闭并处理相关错误；Scanner 本身不会替调用方承担资源所有权。若输入会一直阻塞，行数和字节限制也不能代替输入源的超时或取消设计。

用什么指标判断结果已经可解释

固定输入按规则应形成四条记录：cedar、空字符串、maple、cedar。CRLF 不进入第一条文本，最后一个 cedar 即使没有末尾换行也应被保留。这是预期记录说明，不是实测日志。还应准备“空输入”“仅换行”“正常短行后接超长行”和“Reader 途中失败”等条件，分别写明期望。

观察字段可以分成四组：原始输入是否一致、成功交付条数、失败发生在几条完整记录之后、最终输出是否按输入序号排列。改成并发后，再测端到端耗时、峰值内存和队列占用；在没有测量前，不声称复制方案更快，也不声称并发一定有收益。

为什么调大 Buffer 后，内容变化暂时消失？

缓冲行为变化可能改变复用时机，但没有建立独立所有权。应修正保存数据的方式，不把某次没有出现问题当成 Bytes 可以长期保存的保证。

Text 已经保存为字符串，为什么顺序仍不同？

内容所有权与处理顺序不同。若异步任务按完成时间输出，顺序自然可能不同；需要输入顺序时，让序号参与汇总。

Err 为 nil 就表示所有业务记录都成功了吗？

它只说明扫描层未报告非 EOF 错误。业务过滤、解析失败和下游写入失败需要由各自处理层记录，不能只依赖 Scanner.Err。