Go bufio.Reader.ReadByte 的单字节读取与 EOF 处理方案

做文本协议或轻量词法解析时，我经常先用 bufio.Reader.ReadByte 取一个字节，再决定它是内容、分隔符还是输入结束。这个方法的关键不是忽略第二个返回值，而是先判断 error：成功时使用返回的字节；出错时返回的 byte 没有定义，不能拿它继续拼接结果。输入自然结束通常是 io.EOF，底层 I/O 的其他错误则应该保留下来。

一、ReadByte 的返回值先看 error

bufio.Reader 会把输入源包装成带缓冲的读取器。调用 ReadByte 时，它从已有缓冲取一个字节；缓冲为空时，再向底层读取器补充数据。对调用方而言，稳定的判断表只有三行：

这一点来自 io.ByteReader 的接口约定：如果返回错误，就没有输入字节被消费，返回的 byte 值未定义。因此不要写成“只要 b 不为 0 就算读到了”，也不要在错误分支继续追加 b。

二、EOF 与其他错误要分开处理

逐字节读取最实用的场景是把一段输入切成 token。下面的函数把空格和换行视为当前 token 的边界；遇到 EOF 时，如果前面已经积累了内容，就把它作为最后一个 token 收尾。

func readToken(r *bufio.Reader) ([]byte, error) {
    var token []byte
    for {
        b, err := r.ReadByte()
        if err != nil {
            if errors.Is(err, io.EOF) {
                // 文件末尾是正常结束，返回尚未遇到分隔符的尾部内容。
                return token, nil
            }
            // 其他底层错误不能伪装成正常 EOF，要保留错误原因。
            return nil, fmt.Errorf("读取 token 失败: %w", err)
        }
        if b == ' ' || b == '\n' || b == '\t' {
            // 分隔符已消费，当前 token 在这里结束。
            return token, nil
        }
        // 只有 err == nil 时，返回的字节才可以加入结果。
        token = append(token, b)
    }
}

调用方要决定空 token 是否有意义。若输入以分隔符开头，上面的函数会返回空切片；这属于业务规则，不是 ReadByte 的异常。若底层读取器返回网络断开、权限错误等其他错误，则不要用 io.EOF 的分支吞掉它。

三、缓冲状态和回退操作的边界

ReadByte 成功后，bufio.Reader.Buffered() 可以查看当前缓冲中还剩多少字节，但它不是底层文件或连接的全局偏移量。解析协议时，这个值只适合回答“缓冲层眼下还有多少可读数据”，不能拿来推断已经从网络读取了多少字节。

如果刚读出的一个字节需要交给后续分支判断，可以紧接着调用 UnreadByte。它只允许回退最近一次读取操作；Peek、Discard 等操作会破坏这条回退条件。回退失败应当检查错误，不要假定游标一定恢复。

b, err := reader.ReadByte()
if err != nil {
    // 错误时 b 未定义，不能调用 UnreadByte，也不能继续解析。
    return err
}
if b == ':' {
    // 仅在成功 ReadByte 后回退，交给后续解析分支重新消费。
    if err := reader.UnreadByte(); err != nil {
        return fmt.Errorf("回退分隔符失败: %w", err)
    }
}

相关问题

ReadByte 返回 io.EOF 时 byte 应该取什么值

不要取返回的 byte。错误非空时它没有定义；只根据 errors.Is(err, io.EOF) 判断输入是否自然结束。

ReadByte 适合替代所有按行读取吗

不适合。它适合协议前缀、单字节分隔符和小型词法解析；按行读取应优先评估 ReadString、ReadBytes 或 Scanner 的边界。

为什么其他错误不能当成 EOF

EOF 表示没有更多输入，网络或文件错误则表示读取过程异常。混在一起会让调用方误把不完整数据当成合法结果。