Go bytes.Reader 怎么实现可回退的二进制解析

解析二进制协议时，最容易失控的不是按顺序读字段，而是“先试读一个分支，发现不匹配后再回到原位置”。bytes.Reader 适合处理这种场景：它只读底层字节切片，内部保存当前游标，并通过 Seek 实现回退。实践中要记住一条边界：Seek 到超过数据长度的位置本身可以成功，但后续 Read 会得到 io.EOF；负位置和非法 whence 才是立即的定位错误。

官方文档：https://pkg.go.dev/bytes

先把顺序游标和回退点分开

bytes.NewReader 创建的是只读 Reader。连续调用 Read 会推进内部位置，而 Size 返回底层切片原始长度，Len 返回当前位置之后仍可读取的字节数。二进制解析器可以在尝试字段前记录绝对偏移，再根据分支结果决定提交还是回退。

package main

import (
	"bytes"
	"fmt"
	"io"
)

func readCandidate(data []byte) ([]byte, error) {
	r := bytes.NewReader(data)
	mark, err := r.Seek(0, io.SeekCurrent)
	if err != nil {
		return nil, err // 保存游标失败时不要继续解析分支
	}

	header := make([]byte, 2)
	if _, err := io.ReadFull(r, header); err != nil {
		return nil, err // 头部不完整，直接把截断错误交给调用方
	}
	if !bytes.Equal(header, []byte{0x7f, 'G'}) {
		if _, err := r.Seek(mark, io.SeekStart); err != nil {
			return nil, err // 分支不匹配时恢复到试读前的位置
		}
		return nil, fmt.Errorf("unknown header")
	}

	return header, nil // 标记匹配，当前位置自然成为后续字段起点
}

这里保存的是 Reader 的绝对偏移，而不是“刚才读了 2 字节”这种外部计数。这样即使后续把头部读取改成 ReadFull，回退位置仍然由 Reader 自己定义，分支代码也更容易维护。

用 Seek 实现保存、试读和回退

Seek 支持 io.SeekStart、io.SeekCurrent 和 io.SeekEnd。推荐把“保存点”和“提交点”写成局部变量：保存点用于失败回退，读取成功后不必额外调整，因为顺序读取已经把游标推到下一个字段。

回退时优先使用 io.SeekStart 配合已经记录的绝对位置。io.SeekCurrent 更适合“向后跳过固定长度”这类局部操作，但如果当前分支里又发生了不定长读取，继续累加相对偏移很容易把回退点算错。

把越界、负位置和 EOF 分成三类

调用 Seek 到数据末尾之后的位置并不会自动报错，返回的位置可能大于 Size()。这在预留字段或可选尾部解析中是允许的，但真正读取时要判断 io.EOF。相反，算出负位置时，Seek 会返回错误，不能把返回的 0 当成有效起点继续用。

如果只是判断某个偏移上是否存在可选字段，使用 ReadAt 更稳妥。它按绝对偏移读取，不会污染主游标，适合“探测后仍按原顺序继续”的解析路径；如果需要确认整个缓冲区已读满，可结合 io.ReadFull，不要只看 n。

把回退策略收进解析器

可维护的写法通常只有三个动作：进入分支前保存游标，分支失败时按绝对位置回退，分支成功时让游标自然前进。不要在多个函数之间共享一个“上次位置”全局变量，也不要把 Reader 当成可并发共享对象；需要并发探测时，为每个解析任务建立独立 Reader，或使用不改变主游标的 ReadAt。

最终检查可以按这张清单执行：是否记录了绝对偏移；是否检查每次 Seek 的错误；是否用 io.ReadFull 处理定长字段；是否区分了超过末尾和负位置；是否能证明探测操作没有改变主游标。

相关问题

Seek 到超过 Size 的位置一定报错吗？

不一定。只要最终位置不是负数，定位可以成功；后续读取通常返回 io.EOF。

什么时候用 ReadAt 而不是回退 Seek？

当读取只是探测、且主解析游标必须保持不变时，用 ReadAt 更直接。

为什么回退后还要重新清理状态？

Seek 会重置与 Rune 读取相关的前置状态；如果代码混用了 ReadRune、UnreadRune，应把回退点设计在明确的字节边界上。