Go bufio.Reader ReadSlice 分片处理超长行

用 bufio.Reader.ReadSlice('\n') 读取超长行时，遇到 bufio.ErrBufferFull 不代表整行无效，而是表示当前缓冲区已满、但还没有找到分隔符。正确做法是先处理这次返回的片段，再继续调用 ReadSlice，直到遇到换行符、EOF 或业务规定的单行长度上限。

最容易踩坑的地方是切片生命周期：ReadSlice 返回的字节直接指向 Reader 内部缓冲区，下一次 I/O 操作会覆盖它。需要拼成完整行时，必须在下一次读取前把片段写入自有缓冲；能够分片处理时，则应立即把片段交给哈希、解析器或输出端。

先看旧写法为什么卡在超长行

逐行读取常见的三个选择是 Scanner、ReadString/ReadBytes 和 ReadSlice。Scanner 使用方便，但 token 有最大尺寸约束，虽然可以通过 Scanner.Buffer 调整；ReadString 和 ReadBytes 会为整行持有独立数据，适合普通行；ReadSlice 暴露内部缓冲区切片，最适合需要控制分配或分片处理的场景。

因此，采用 ReadSlice 并不是“把缓冲区调大”的替代说法，而是改变调用方与缓冲区之间的契约：调用方承认一行可能被拆成多个片段，并负责片段累计、大小限制和最终行结束策略。

建立超长行的分片规则

官方文档说明，ReadSlice 会读到第一个分隔符并把分隔符包含在返回切片中。如果在找到分隔符前缓冲区被填满，它返回当前缓冲区内的全部数据和 ErrBufferFull；如果先遇到其他错误，则返回已有数据和该错误，常见的是 io.EOF。

可以把每次返回归纳为三类：

• err == nil：当前片段以分隔符结束，一行已经完整。
• errors.Is(err, bufio.ErrBufferFull)：当前片段只是中间部分，应先保存或消费，再继续读取。
• 其他错误：当前片段是错误前读到的数据，是否接受取决于 EOF 与业务规则。

拼接完整行的最小可用写法

下面的函数把超长行安全拼接为独立字节切片，并限制单行最大长度。bytes.Buffer.Write 会复制片段，因此下一次 ReadSlice 覆盖内部缓冲区时，已经保存的数据不会变化。

func readLongLine(r *bufio.Reader, maxLine int) ([]byte, error) {
    var line bytes.Buffer

    for {
        fragment, err := r.ReadSlice('\n')

        // 在下一次读取前检查并复制当前片段
        if line.Len()+len(fragment) > maxLine {
            return nil, fmt.Errorf("单行超过 %d 字节上限", maxLine)
        }
        if _, writeErr := line.Write(fragment); writeErr != nil {
            return nil, fmt.Errorf("保存行片段失败: %w", writeErr)
        }

        switch {
        case err == nil:
            // 已读到换行符，返回不含行尾的独立副本
            return bytes.TrimSuffix(line.Bytes(), []byte{'\n'}), nil

        case errors.Is(err, bufio.ErrBufferFull):
            // 当前只是中间片段，继续读取同一行的剩余部分
            continue

        case errors.Is(err, io.EOF) && line.Len() > 0:
            // 接受文件末尾没有换行符的最后一行
            return line.Bytes(), nil

        default:
            // 无数据 EOF 或其他底层错误由调用方处理
            return nil, err
        }
    }
}

这里把结尾换行符去掉了，但没有自动去除 \r。处理 CRLF 文本时，应在完整行结束后按协议规则去掉 \r\n，不要对每个中间片段单独 TrimSpace，否则可能误删属于正文的空白。

分片消费，避免持有整条超长行

如果任务是计算哈希、转存、计数或增量解析，不一定要把整行拼在内存里。片段可以在下一次读取前直接交给下游。这样单行即使很长，Reader 与处理器也只持有有限大小的活动数据。

func consumeLongLine(
    r *bufio.Reader,
    maxLine int,
    consume func([]byte) error,
) error {
    total := 0

    for {
        fragment, err := r.ReadSlice('\n')
        total += len(fragment)

        // 总长度上限防止无分隔符输入无限占用资源
        if total > maxLine {
            return fmt.Errorf("单行超过 %d 字节上限", maxLine)
        }

        // consume 必须在返回前用完片段，不能保存借用切片
        if len(fragment) > 0 {
            if consumeErr := consume(fragment); consumeErr != nil {
                return fmt.Errorf("消费行片段失败: %w", consumeErr)
            }
        }

        switch {
        case err == nil:
            return nil // 已消费包含换行符的最后一个片段
        case errors.Is(err, bufio.ErrBufferFull):
            continue // 继续读取当前超长行
        case errors.Is(err, io.EOF) && total > 0:
            return nil // 按当前策略接受无结尾换行的最后一行
        default:
            return err
        }
    }
}

回调如果需要异步保存片段，必须自行复制，例如 append([]byte(nil), fragment...)。直接把 fragment 放进 channel 再继续读取，会把一个即将失效的缓冲区视图交给其他 goroutine，结果可能表现为内容变化或数据竞争。

单行上限是必要的业务规则

分片循环解决了“缓冲区装不下一整行”，但没有自动解决“输入永远没有分隔符”。如果对端持续发送字节而不发送换行，盲目拼接会让内存不断增长；即使采用流式消费，也可能让一个逻辑记录无限延长。因此应根据协议、日志格式或数据源设置明确的 maxLine。

长度上限要计算原始字节，而不是 rune 数。ReadSlice 的分隔符和缓冲区都以 byte 工作，UTF-8 汉字可能占多个字节。若业务最终按字符数限制，应先在字节上限保护之后，再对完整文本做 UTF-8 校验与字符统计。

当超限发生时，还要决定如何恢复：

• 面向文件导入，可以报告行号和上限后停止，避免后续记录错位。
• 面向网络协议，通常应关闭连接或丢弃到下一个可信边界。
• 面向容错日志，可丢弃当前行剩余片段，但必须记录截断事件。

明确换行符和 EOF 的兼容语义

ReadSlice 成功时，返回值包含分隔符；发生错误时，返回值不以分隔符结束。这一条很适合用作断言，但调用方仍要定义业务结果：保留 \n、去掉 \n，还是统一处理 \r\n。

EOF 也不是只有一种情况。若 fragment 为空且 err 为 io.EOF，表示没有更多行；若 fragment 非空且 err 为 io.EOF，表示文件以一个没有换行符的末尾记录结束。许多文本格式接受后者，但某些逐帧协议要求严格分隔，此时应返回“缺少结束符”而不是把它当作成功。

按场景选择读取 API

如果每行只需做简单解析，已知最大长度也不大，优先使用 Scanner 并通过 Buffer 明确最大 token；如果需要一个完整字符串或字节切片，且可接受整行分配，ReadString 或 ReadBytes 更省代码；如果单行可能很长、希望复用缓冲区或边读边处理，ReadSlice 才能体现价值。

ReadSlice 是底层 API。它把分配策略和错误边界交给调用方，因此代码会更长，但也能精确控制片段何时复制、整行是否保留、超限后如何恢复。不要仅为“性能看起来更好”就使用它；只有当所有权和内存模型确实需要这种控制时才值得。

常见问题

ErrBufferFull 需要扩大 Reader 缓冲区吗？

不一定。扩大缓冲区能减少片段数量，但不能保证容纳任意长的行。若设计目标就是分片处理，正确响应是先消费当前片段并继续读取，同时保留单行总长度上限。

ReadSlice 返回的 fragment 可以长期保存吗？

不可以直接保存。它指向 Reader 内部缓冲区，下一次 I/O 操作后可能失效。长期保存时要复制，或者在下一次读取前同步消费完。

为什么不用 Scanner.Buffer 解决所有问题？

Scanner.Buffer 适合为 token 设置可控上限，但 Scanner 仍以完整 token 为交付单位。需要边读边处理一个超长逻辑行时，ReadSlice 的片段语义更直接。

最后一行没有换行符算错误吗？

由数据格式决定。普通文本常接受，严格行协议可能拒绝。代码应显式写出策略，而不是把所有 io.EOF 都当作同一种结果。

官方资料

ReadSlice、ReadBytes、ReadString 与 Scanner.Buffer 的官方文档：https://pkg.go.dev/bufio；实现细节可参考：https://go.dev/src/bufio/bufio.go。

处理超长行的核心不是消灭 ErrBufferFull，而是正确解释它：当前片段有效、整行尚未结束、借用切片即将失效。把复制时机、累计上限与 EOF 语义写成明确规则，ReadSlice 才能成为稳定的分片接口。