bufio.Reader ReadLine 处理软换行与长文本

我第一次用 bufio.Reader.ReadLine 处理日志流时，最容易误判的一点是：函数返回了一段字节，并不代表这一段就是完整的逻辑行。只要物理行超过 Reader 的缓冲区，它就会通过多次调用返回片段，isPrefix 负责告诉我们后面是否还有同一行的内容。

这篇只围绕一个问题展开：如何把 ReadLine 的软换行片段安全地拼成一条长文本。核心做法是保留每一段直到下一次读取前，把片段追加到自己的缓冲区；当 isPrefix 变为 false 时，才把它交给上层处理。

把 ReadLine 看成“取下一段”，不要看成“取完整行”。isPrefix=true 时继续拼接，isPrefix=false 时才完成一条逻辑行；如果数据要跨越下一次 ReadLine 使用，就必须复制到调用方拥有的内存。

先把三个返回值放回正确语境

ReadLine 的签名是 (line []byte, isPrefix bool, err error)。line 是当前片段，不含行尾；isPrefix 为 true 时表示这一段只是长行的前缀，后续调用还会继续返回同一行；err 则表示读取过程遇到了错误。官方文档还特别说明：返回的缓冲区只保证在下一次调用 ReadLine 之前有效。

因此，下面两种输入要区分开：短行可能一次返回且 isPrefix=false；超长行可能先返回多个 isPrefix=true 的片段，最后一段才是 false。这里的“软换行”不是输入里真的多了换行符，而是 Reader 为了适应缓冲区而做的分段。

用循环拼接一条完整逻辑行

实际代码可以把“读取一段”和“完成一行”分成两个边界：每次拿到片段就追加；只有 isPrefix 为 false 时才返回累积结果。使用 bytes.Buffer 的好处是它由调用方持有，下一次 ReadLine 不会改写已经追加的数据。

package main

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

// readLogicalLine 把 ReadLine 返回的多个片段合并成一条逻辑行。
func readLogicalLine(r *bufio.Reader) ([]byte, error) {
    var joined bytes.Buffer

    for {
        fragment, isPrefix, err := r.ReadLine()
        if err != nil {
            // EOF 前没有任何片段时，交给调用方判断是否结束输入。
            if err == io.EOF && joined.Len() == 0 {
                return nil, io.EOF
            }
            return nil, err
        }

        // 每次追加到自有缓冲，避免下一次 ReadLine 覆盖返回切片。
        _, _ = joined.Write(fragment)
        if !isPrefix {
            // false 表示当前逻辑行已经读完，可以交给上层。
            return joined.Bytes(), nil
        }
    }
}

func main() {
    // 用一个明显超过小缓冲区的逻辑行模拟长文本输入。
    input := strings.NewReader("前缀-" + strings.Repeat("内容", 80) + "-结尾\n下一行\n")
    reader := bufio.NewReaderSize(input, 16)

    for {
        line, err := readLogicalLine(reader)
        if err == io.EOF {
            // 没有剩余数据时正常结束，不把 EOF 当成坏数据。
            break
        }
        if err != nil {
            panic(fmt.Errorf("读取逻辑行失败: %w", err))
        }
        fmt.Printf("%d bytes: %s\n", len(line), line[:min(len(line), 20)])
    }
}

// min 只用于限制示例输出长度，不参与 ReadLine 的拼接逻辑。
func min(a, b int) int {
    if a 

这个函数的关键不在于缓冲区设成多大，而在于以 isPrefix 作为逻辑边界。即使 Reader 的内部缓冲区调整了大小，调用方仍然按同一规则处理长行。若上层只想消费流而不需要保留整行，也可以在每次片段到达时直接处理，但必须明确“片段处理”与“完整行处理”不是同一件事。

没有结尾换行时，EOF 应该怎么处理

ReadLine 不要求输入最后一定有 \n。最后一段可以在没有行尾的情况下以 isPrefix=false 返回，调用方应该把它视为一条完成的逻辑行。只有下一次读取时没有任何新片段并返回 io.EOF，才说明输入已经结束。

工程上最常见的错误是看到 EOF 就丢弃当前缓冲区，或者只在读取到换行符时提交数据。更稳妥的判断是：先看本次是否已经拿到片段，再看是否还有前缀；错误和已读数据若同时出现，则必须按照具体 Reader 的约定决定是否保留数据，不要用一个统一的字符串判断覆盖所有情况。

返回的 []byte 为什么不能长期保存

官方文档把这条生命周期限制写得很直接：ReadLine 返回的缓冲区在下一次读取后就可能失效。把 line 直接放进一个长期保存的切片或结构体，短时间内看起来可能没问题，但下一次调用后，它可能已经指向被复用或覆盖的内部空间。

如果必须把当前片段交给异步任务、缓存、消息队列或跨越下一次读取的对象，复制是最清楚的做法：

// copyFragment 返回一份由调用方拥有的独立数据。
func copyFragment(fragment []byte) []byte {
    owned := make([]byte, len(fragment))
    copy(owned, fragment)
    return owned
}

// appendFragment 适合把片段追加到已经拥有的累计切片。
func appendFragment(owned, fragment []byte) []byte {
    // append 可能扩容，扩容后的底层数组由 owned 持有，不依赖 Reader。
    return append(owned, fragment...)
}

前面的 bytes.Buffer 示例已经完成了同类复制：Write 把数据写入自己的存储。对于极短片段，直接 append 通常更简单；对于需要复用容量的读取器，可以预估上限并使用自己的字节切片。无论选哪种容器，责任边界都一样：ReadLine 的返回值只负责交付当前片段，不负责替调用方长期保管。

什么时候不该继续使用 ReadLine

ReadLine 是较底层的原语，适合需要精确控制缓冲和片段的场景。若只是想读取普通的换行文本，ReadString('\n') 或 ReadBytes('\n') 会直接帮你收集到分隔符；如果输入是常规的小令牌，Scanner 的接口更易读。不过 Scanner 有自己的 token 大小上限，需要大 token 时应显式调整缓冲区，或者回到 Reader 路径自行决定如何消费。

我会保留的排查清单

1. 调用点是否把一次 ReadLine 误认为一次完整逻辑行？
2. 是否在 isPrefix=true 时继续追加，而不是提前提交？
3. 是否允许最后一行没有换行符，并把真正的 EOF 留给下一次读取？
4. 返回的 []byte 是否会跨越下一次 ReadLine 使用？如果会，是否已经复制？
5. 业务真正需要的是片段控制、分隔符读取，还是普通按行扫描？是否选对了 API？

ReadLine 的难点其实不在 API 数量，而在“物理片段”和“逻辑记录”之间多了一层边界。只要把 isPrefix 当成生命周期信号，把返回切片当成临时借用，再把错误和 EOF 分开处理，长文本读取就不会因为缓冲区大小变化而悄悄截断。

相关问题

isPrefix=true 时能不能直接把片段交给业务？

可以，但前提是业务明确处理的是片段而不是完整逻辑行。如果业务需要一条完整记录，就必须继续读取并追加，直到 isPrefix=false。

ReadLine 返回的 line 需要手动去掉换行符吗？

不需要。ReadLine 返回的内容不包含 \n 或 \r\n 行尾；如果业务要保留原始行尾，需要选用能返回分隔符的读取方式，或在业务层重新添加。

为什么不用 Scanner 读取所有长文本？

Scanner 更方便，但它有 token 大小限制，而且遇到过大的 token 会停止。需要更细的错误控制、持续读取或自定义长行策略时，Reader 更合适。