Go bufio.Reader.ReadBytes 遇到 EOF 时怎么判断记录是否完整

用 bufio.Reader.ReadBytes(delim) 读取文件或长连接时，判断记录是否完整不能只看 err。最可靠的规则是：返回数据以分隔符结尾时，记录完整且 err == nil；返回数据没有分隔符时，io.EOF 表示流结束前留下了一段尾数据，这段数据是否算记录要由业务协议决定；没有数据且收到 io.EOF，才是干净结束。

官方文档：

https://pkg.go.dev/bufio#Reader.ReadBytes

先把 ReadBytes 的返回契约固定下来

ReadBytes 从当前缓冲位置读到第一个分隔字节，并把分隔字节一起放进返回切片。如果在找到分隔字节之前底层读取遇到错误，它仍会返回已经读到的数据和错误。官方契约还给出了一个很实用的判断：只要返回数据没有以分隔字节结尾，err 就不会是 nil。

因此，下面这类代码不能把任何非空数据都直接当成完整记录：

chunk, err := reader.ReadBytes('\n')
// ReadBytes 会把换行一起返回，先判断记录是否真的带有终止符。
complete := len(chunk) > 0 && chunk[len(chunk)-1] == '\n'
if complete && err == nil {
    // 只有到达分隔符且没有错误时，才按完整记录处理。
    consumeRecord(chunk)
}

如果读取的分隔符不是换行，例如协议使用 0x04 作为消息结束字节，完整性判断也必须使用同一个字节，不能把“有数据”误当成“有终止符”。

把 EOF 分成三种输入状态

很多导入 bug 都来自把 io.EOF 直接当成失败。对 ReadBytes 来说，至少要区分下面三种状态。

非 EOF 错误要单独处理。它可能来自底层文件、连接或自定义 io.Reader，此时返回切片仍可能包含有用的部分数据，但不能因为“有数据”就提交成完整记录。

在循环里保留同一个 Reader

读取连续记录时，应在循环外创建一次 bufio.Reader。Reader 自己维护着缓冲区，反复用新的 Reader 包装同一个底层流，可能丢掉前一个缓冲实例已经预读的数据。

package main

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

// readRecords 读取以换行结束的记录，并返回是否发现不完整尾记录。
func readRecords(src io.Reader, acceptTail bool) ([][]byte, bool, error) {
    reader := bufio.NewReader(src)
    var records [][]byte
    var tailIncomplete bool

    for {
        chunk, err := reader.ReadBytes('\n')
        // ReadBytes 返回的数据可能同时包含业务内容和终止字节。
        complete := len(chunk) > 0 && chunk[len(chunk)-1] == '\n'
        if complete {
            // 复制一份，避免把后续处理和底层缓冲生命周期混在一起。
            records = append(records, bytes.TrimSuffix(append([]byte(nil), chunk...), []byte{'\n'}))
        }

        if err == nil {
            // 找到分隔符后继续读取下一条记录。
            continue
        }
        if errors.Is(err, io.EOF) {
            if len(chunk) == 0 {
                // 没有尾数据的 EOF 是正常结束。
                return records, tailIncomplete, nil
            }
            if !complete {
                // 尾数据没有换行，是否接受由调用方的协议策略决定。
                tailIncomplete = true
                if acceptTail {
                    records = append(records, append([]byte(nil), chunk...))
                }
            }
            return records, tailIncomplete, nil
        }
        // 非 EOF 错误不能被吞掉，即使本次返回了部分字节。
        return records, tailIncomplete, fmt.Errorf("读取记录失败: %w", err)
    }
}

这个函数把三个决策分开了：是否有终止符决定记录完整性，io.EOF 决定流是否结束，acceptTail 决定协议是否接受没有换行的最后一段。这样导入任务可以把尾记录单独计数，而不是把它和底层 I/O 失败混为一谈。

尾记录到底该接受还是拒绝

答案取决于数据格式，而不是 Go 的默认偏好。对日志、人工编辑的文本或允许最后一行没有换行的格式，可以接受非空尾数据，并在记录元数据中标记“无终止符”。对行协议、批量交换文件或要求每条消息都有结束标记的格式，则应拒绝或进入待补偿队列。

一个简单的策略表如下：

• 允许尾记录：保存数据，同时记录 tail_without_delim=true，便于后续审计。
• 必须有终止符：不提交这段数据，返回一个业务层的不完整记录错误。
• 无法判断格式：保留原始字节和偏移信息，交给上层重试或人工处理。

注意，ReadBytes 返回的是字节切片。若数据本身是 UTF-8 文本，记录完整性先按字节分隔符判断，再在业务层做文本解码；不要用字符数量代替分隔符判断。

非 EOF 错误和三个常见误区

误区一：看到 EOF 就丢弃返回数据

当 chunk 非空且没有终止符时，EOF 只说明底层输入已经结束，并不说明这些字节不存在。是否保存应由尾记录策略决定。

误区二：只判断 err == nil

err == nil 只能说明这次读取成功找到分隔符；真正提交前仍应确认返回数据确实以预期分隔符结尾，尤其是在封装了自定义 Reader 的场景中。

误区三：每次循环都重新创建 bufio.Reader

Reader 的缓冲可能已经从底层输入读入了后续字节。循环内丢掉 Reader，会让缓冲中的数据不再被当前代码消费。正确做法是在循环外创建一次，并让所有记录读取共享它。

速查：ReadBytes 的判断顺序

1. 先检查返回切片是否为空，以及末尾是否是目标分隔符。
2. 有分隔符时按完整记录处理；通常此时 err 应为 nil。
3. 无分隔符且 errors.Is(err, io.EOF) 时，把非空数据视为尾记录候选。
4. 无分隔符且是其他错误时，保留部分数据并上报底层错误。
5. 空数据加 io.EOF 时结束循环。

归纳起来，ReadBytes 的核心不是“遇到 EOF 就退出”，而是同时读取返回数据、终止符和错误三件事。把完整性判断与业务是否接受尾记录分开，文件导入和流式协议的边界就会清楚很多。

相关问题

ReadBytes 和 ReadString 的判断方式一样吗？

一样：两者都把分隔符包含在返回值中，并在找不到分隔符而遇到错误时返回已读内容和错误。区别主要是返回类型，一个是字节切片，一个是字符串。

没有终止换行的最后一行能不能算合法数据？

可以，但要由文件格式或业务协议明确允许。建议把它标记为尾记录，而不是悄悄当成普通完整记录。

应该改用 Scanner 吗？

如果只需要简单分行，Scanner 更方便；如果需要保留错误、处理较大记录或精确控制读取边界，bufio.Reader 通常更合适。两者的选择不改变“尾数据是否完整”必须由协议决定这一点。