Go bufio.Scanner 扫描二进制零字节数据时如何改用 Reader

把二进制流交给 bufio.Scanner 后，最容易误判的不是中文编码，而是 0x00 到底是什么：它可能只是 payload 中的一个合法字节，也可能是协议约定的帧分隔符。若零字节只是数据，不能用“读到 0 就结束”的文本思路；若它确实是分隔符，改用 bufio.Reader.ReadBytes(0) 更合适。固定长度协议则应直接使用 io.ReadFull。

先判断 0x00 是数据还是记录边界

二进制格式里，0x00 没有“天然结束”的特殊地位。比如一个字段可能用零字节填充，正文里也可能连续出现多个零字节；只有协议明确规定“第一个零字节结束当前字段”，它才是 delimiter。这个判断决定了读取算法。

Scanner 的限制不在于“不能读二进制”

Scanner 接收的是 io.Reader，本身可以接触任意字节；真正的边界来自 split 函数和 token 缓冲。默认 split 是 ScanLines，而 ScanBytes 会把每个字节作为一个 token，所以零字节不会被它神奇地过滤掉。

更需要注意的是默认 MaxScanTokenSize 为 64 KiB，实际可用上限还要给分隔符等缓冲空间留余量。token 过大时，扫描会停止并报告 bufio.Scanner: token too long；停止后底层 reader 可能已经前进了一段，不能把同一个 reader 当作完全未读来重试。

如果只是文本行偶尔超过限制，可以在第一次 Scan 前调用 Buffer：

scanner := bufio.NewScanner(r)
// 提前设置上限；Buffer 不能在 Scan 已经开始后调用。
scanner.Buffer(make([]byte, 64*1024), 4*1024*1024)
for scanner.Scan() {
    // ScanLines 仍然负责切行，正文按文本处理。
    consume(scanner.Bytes())
}
if err := scanner.Err(); err != nil {
    // 读取失败和 token 超限都必须显式交给调用方。
    return err
}

但这只是扩大 token 上限，不会改变 Scanner 的“按 token 停止”语义。要保留二进制边界和读取错误，通常应该换成 Reader。

零字节确实是分隔符时，用 Reader.ReadBytes

ReadBytes(0) 会一直收集到第一个零字节，并把分隔符一起返回；没有找到分隔符就遇到 io.EOF 时，返回已读数据和错误。二进制字段可能很长时，它比 ReadSlice 更适合直接交给业务层，因为 ReadSlice 可能返回 bufio.ErrBufferFull，且返回的缓冲会被下一次读取覆盖。

func readNULField(br *bufio.Reader) ([]byte, error) {
    raw, err := br.ReadBytes(0)
    // 找到 0x00 时，raw 最后一个字节就是协议分隔符。
    if len(raw) > 0 && raw[len(raw)-1] == 0 {
        return raw[:len(raw)-1], nil
    }
    // 没有分隔符的尾部数据不能伪装成完整字段。
    if err != nil {
        return raw, fmt.Errorf("读取零字节字段: %w", err)
    }
    return raw, errors.New("读取零字节字段: 缺少分隔符")
}

func readFields(r io.Reader) ([][]byte, error) {
    br := bufio.NewReaderSize(r, 32*1024)
    var fields [][]byte
    for {
        field, err := readNULField(br)
        if err != nil {
            if errors.Is(err, io.EOF) && len(field) == 0 {
                // 空尾部表示输入正常结束，不再产生一个虚字段。
                return fields, nil
            }
            return nil, err
        }
        fields = append(fields, field)
    }
}

这里的停止条件来自协议分隔符，而不是来自文本换行。若尾部没有 0x00，示例会把它当作不完整字段；如果业务允许“最后一个字段可以无分隔符”，应在收到 io.EOF 时单独定义兼容策略。

固定长度帧不要扫描分隔符

如果帧头已经给出 payload 长度，最稳妥的做法是先解析长度，再用 io.ReadFull 读满指定字节数。这样即使 payload 中有十个连续零字节，也只会被当作普通数据。

func readFrame(r io.Reader) ([]byte, error) {
    var header [4]byte
    // 固定读取 4 字节长度头，短读时由 io.ReadFull 返回错误。
    if _, err := io.ReadFull(r, header[:]); err != nil {
        return nil, fmt.Errorf("读取帧头: %w", err)
    }
    size := binary.BigEndian.Uint32(header[:])
    // 上限是业务防护，不让不可信长度造成过大分配。
    if size > 4*1024*1024 {
        return nil, fmt.Errorf("帧长度 %d 超过上限", size)
    }
    payload := make([]byte, size)
    // payload 的 0x00 不参与边界判断，只按 size 读取。
    if _, err := io.ReadFull(r, payload); err != nil {
        return nil, fmt.Errorf("读取帧内容: %w", err)
    }
    return payload, nil
}

该方案的前提是长度字段可信且协议有最大帧大小。长度字段不可信时，先做上限检查；上限不是越大越好，而是和内存预算、单条业务记录大小共同决定。

把读取方式写进排查清单

迁移代码时，可以先回答四个问题：零字节是 payload 还是 delimiter？记录是否有固定长度？单条数据最大多大？短读、缺分隔符和 EOF 是否要区分？答案明确后，API 选择通常不会摇摆。

• 有稳定文本 token、长度可控：保留 Scanner，必要时在扫描前调用 Buffer。
• 分隔符是单个零字节、字段长度不固定：使用 Reader.ReadBytes(0)，并检查尾部是否真的带分隔符。
• 帧长度已知或 payload 可包含任意字节：使用 io.ReadFull，不要靠扫描内容猜边界。
• 需要在一次失败后继续从精确位置解析：优先选择 Reader 或直接控制 io.Reader.Read，不要依赖 Scanner 失败后的 reader 位置。

常见问题

Scanner 遇到 0x00 会自动停止吗？

不会。是否停止由 split 函数决定；默认 ScanLines 等待换行，ScanBytes 则把零字节当普通的一个字节。

把 Scanner.Buffer 调大后还能读大二进制吗？

可以缓解 token 过大的问题，但仍受 token 语义约束，也不能解决“payload 内零字节与协议分隔符混在一起”的歧义。

ReadBytes(0) 和 ReadSlice(0) 有什么区别？

ReadBytes 会复制并拼接跨缓冲区的数据；ReadSlice 返回内部缓冲切片，遇到缓冲区满会报 ErrBufferFull，下一次读取后内容也可能失效。

固定长度帧读到 EOF 怎么判断？

让 io.ReadFull 返回错误并向上层传递；它能区分完全读满、输入提前结束等情况，比把短数据当成成功 payload 更安全。