Go Reader 怎样拼接跨缓冲区的一行

用 bufio.Reader.ReadSlice('\n') 读文本时，如果一行比内部缓冲区更长，方法不会直接返回“完整的一行”，而是返回当前片段和 bufio.ErrBufferFull。正确做法是先复制这段数据，再继续调用 ReadSlice，直到拿到最后一段，最后用 bytes.Join 拼回完整内容。

官方文档：https://pkg.go.dev/bufio#Reader.ReadSlice

关键有两点：ReadSlice 返回的切片只在下一次读之前有效；遇到 ErrBufferFull 时，当前片段已经交付给调用方，必须复制后才能继续读取。

先看 ReadSlice 为什么会返回片段

ReadSlice 会在 Reader 的内部缓冲区里寻找指定分隔符。以换行符为例，如果当前缓冲区装满了仍然没有找到 \n，它就返回目前能交付的字节，并把错误设为 bufio.ErrBufferFull。这不是说输入流损坏，而是告诉调用方：这一行还没有结束，后面仍可能有同一行的内容。

标准库文档还特别说明，返回的切片指向 Reader 的内部缓冲区，下一次 I/O 可能覆盖它。因此，不能把片段地址长期保存后再调用 ReadSlice。

package main

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

func main() {
    // 使用很小的缓冲区，让一行明确跨过内部缓冲区边界。
    reader := bufio.NewReaderSize(strings.NewReader("前半段内容后半段内容\n"), 8)
    fragment, err := reader.ReadSlice('\n')

    // ErrBufferFull 只说明当前片段还没遇到分隔符，不等于输入失败。
    fmt.Printf("fragment=%q err=%v\n", fragment, err)
}

这里的缓冲区大小只影响一次能拿到多少片段，不代表整行的最大长度。只要调用方愿意持续收集片段，逻辑上就可以处理比单次缓冲区更长的行。

遇到 ErrBufferFull 时先复制再继续

拼接的核心是一个循环：每次拿到片段后，先用 bytes.Clone 拷贝出独立内存；如果错误是 bufio.ErrBufferFull，继续读取；如果没有错误，说明已经遇到分隔符，可以结束循环。复制动作必须发生在下一次读之前，否则后续 I/O 可能改写上一段内容。

package main

import (
    "bufio"
    "bytes"
    "errors"
    "io"
)

func readLine(reader *bufio.Reader) ([]byte, error) {
    var chunks [][]byte

    for {
        fragment, err := reader.ReadSlice('\n')
        if len(fragment) > 0 {
            // 先复制内部缓冲区的片段，下一次读取就不会覆盖它。
            chunks = append(chunks, bytes.Clone(fragment))
        }

        switch {
        case err == nil:
            // 找到换行符，当前片段已经是这一行的最后一段。
            return bytes.Join(chunks, nil), nil
        case errors.Is(err, bufio.ErrBufferFull):
            // 行还没有结束，继续从 Reader 取下一段。
            continue
        case errors.Is(err, io.EOF):
            // 文件末尾可能没有换行符；已有片段仍可作为最后一行。
            if len(chunks) > 0 {
                return bytes.Join(chunks, nil), nil
            }
            return nil, io.EOF
        default:
            // 真实的底层读取错误不能伪装成完整文本。
            return nil, err
        }
    }
}

示例用 errors.Is 判断错误，是为了保留错误包装后的兼容性。若项目需要兼容更老的 Go 版本，也可以用 append([]byte(nil), fragment...) 完成同样的独立复制；原则不变：不要直接把 ReadSlice 返回的内部切片放进长期结果。

用 bytes.Join 还原完整的一行

每个片段已经复制到独立内存后，bytes.Join(chunks, nil) 会按原来的读取顺序连续合并它们。分隔符也会保留在对应片段中，所以带换行的记录可以直接交给后续解析；如果输入在 EOF 处没有换行，最后一段也会被保留下来。

如果只想处理超长行而不需要保留分隔符，可以在合并完成后再去掉末尾的 \n 或 \r\n。不要在每次循环中反复执行字符串拼接，那会让中间结果不断产生新的分配；先收集片段、最后一次合并更容易控制内存行为。

// trimLineEnd 只去掉一行末尾的换行符，不改变正文内容。
func trimLineEnd(line []byte) []byte {
    line = bytes.TrimSuffix(line, []byte("\n")) // 先处理 Unix 换行。
    line = bytes.TrimSuffix(line, []byte("\r")) // 再兼容 Windows 换行。
    return line
}

把 EOF、ErrBufferFull 和其他错误分开

这三个结果的含义不同：

• bufio.ErrBufferFull：当前缓冲区装满，但还没有找到分隔符；片段需要复制并继续收集。
• nil：找到了分隔符；当前片段是最后一段。
• io.EOF：底层输入结束；如果已经收集到内容，可以把它当作没有换行符的最后一行，否则表示没有更多数据。

任何其他错误都应原样返回，例如文件读取失败或网络连接中断。把所有非 nil 错误都当成 ErrBufferFull 会造成循环继续读取，也可能把不完整数据误交给解析器。

func collectLines(reader *bufio.Reader) ([][]byte, error) {
    var lines [][]byte

    for {
        line, err := readLine(reader)
        if errors.Is(err, io.EOF) {
            // EOF 表示没有下一行，不是本次读取失败。
            return lines, nil
        }
        if err != nil {
            // 保留原始错误，方便调用方记录具体故障。
            return nil, err
        }
        lines = append(lines, trimLineEnd(line)) // 保存已经拥有独立内存的完整行。
    }
}

迁移清单与常见误区

1. 确认分隔符是单字节换行，还是需要更高层的字段解析。
2. 遇到 ErrBufferFull 时复制片段，再进入下一轮读取。
3. 最终用 bytes.Join 合并，避免在循环里反复扩容字符串。
4. 把无换行的 EOF 最后一行和空输入区分开。
5. 将其他 I/O 错误向上返回，不要无限重试。

最常见的错误是直接把 fragment 放进切片，下一次调用后才发现历史内容发生变化；另一个错误是看到 ErrBufferFull 就立即返回失败。前者违反了返回切片的生命周期，后者则把正常的长行误判成异常。

相关问题

为什么不直接用 ReadString？如果只需要一个字符串，ReadString('\n') 会直接完成拼接；本文讨论的是需要控制片段生命周期、区分错误或保留字节切片的场景。

ReadSlice 返回的片段一定包含换行符吗？只有在返回 nil 错误时才表示找到了分隔符；遇到 ErrBufferFull 或无换行 EOF 时，片段可能不包含换行符。

能不能把缓冲区调得很大来避免拼接？可以减少跨缓冲区的概率，但会把单次内存成本绑定到配置值，也不能替代对异常长行的处理。需要稳定边界时，复制片段并合并更清晰。