Go bytes.Reader 如何控制缓冲视图

做二进制协议解析时，我常遇到一个很具体的场景：先看前 8 个字节判断版本，再把同一份缓冲交给主体解析器。如果直接连续调用 Read，读取位置会向前走；如果为了看头部而调用 Seek，又容易把主流程的游标弄乱。bytes.Reader 的关键不是“把切片包起来”，而是把同一份字节数据拆成几种可控视图：顺序游标用 Read 和 Seek，绝对偏移用 ReadAt，固定区间则用 io.NewSectionReader。

先把底层字节、顺序游标和原始长度分开

bytes.NewReader 接受一个 []byte，返回一个只读读取器。它实现了 io.Reader、io.ReaderAt、io.Seeker 等接口，因此既可以顺序消费，也可以按位置访问。这里最容易误判的是长度：Len 只返回“还没有读过的部分”，而 Size 返回底层切片的原始长度。

package main

import (
	"bytes"
	"fmt"
)

func inspectReader() {
	data := []byte("HEAD|payload")
	r := bytes.NewReader(data)

	// Len 表示当前游标之后的未读字节数，Size 表示原始切片长度。
	fmt.Println(r.Len(), r.Size())

	buf := make([]byte, 5)
	_, _ = r.Read(buf) // 顺序读取会推进游标，错误应在真实代码中单独处理。

	// 读取后 Len 变小，但 Size 不随顺序读取变化。
	fmt.Println(r.Len(), r.Size())
}

因此，协议解析里不要用 Len 代表“整包大小”。它回答的是“从当前位置还能读多少”；要判断偏移是否落在原始数据内，更适合使用 Size。如果需要换一份数据，调用 Reset 后两者才会按新切片重新计算。

用 ReadAt 做绝对位置读取

当头部预览和主体读取需要并存时，ReadAt 通常比“读完再 Seek 回去”更清楚。偏移量是相对底层切片起点的绝对位置，调用不会改变 Read 和 Seek 共用的顺序游标。要注意它仍然可能发生短读：请求区间超出可用数据时，返回的字节数和错误必须一起判断。

func readHeader(data []byte) ([]byte, error) {
	r := bytes.NewReader(data)
	header := make([]byte, 4)

	// ReadAt 从底层起点偏移 0 读取，不干扰后续顺序读取位置。
	n, err := r.ReadAt(header, 0)
	if err != nil {
		return header[:n], fmt.Errorf("读取头部: %w", err)
	}
	return header, nil
}

如果头部只是用于判断版本、校验魔数或查目录，优先把这类访问做成 ReadAt。主解析器仍可以从自己的游标继续读取；这就是“同一份缓冲，两个访问意图”，而不是复制两份完整数据。

用 Seek 明确移动同一个顺序游标

Seek 适合确实需要改变顺序读取位置的场景，例如重新解析一段内容，或在读取尾部字段前跳过中间区域。它的返回值是移动后的绝对位置，whence 应使用 io.SeekStart、io.SeekCurrent 或 io.SeekEnd，不要把裸数字散落在业务代码中。

func rewindForBody(r *bytes.Reader, bodyOffset int64) error {
	// 从底层起点定位到主体，返回值可用于记录当前绝对位置。
	pos, err := r.Seek(bodyOffset, io.SeekStart)
	if err != nil {
		return fmt.Errorf("定位主体: %w", err)
	}
	if pos  r.Size() {
		return fmt.Errorf("主体位置越界: %d", pos)
	}
	return nil
}

这里的边界判断是业务责任：Seek 能移动游标，不等于它替你验证了后续字段的完整性。若只是旁路检查，不要为了方便修改主游标，回到上一节的 ReadAt 更合适。

用 SectionReader 固定可见窗口

如果主体解析器只负责读取 off 到 off+n 的区间，最稳妥的做法是创建 io.SectionReader。bytes.Reader 已经实现了 io.ReaderAt，可以直接作为底层读取器传入。窗口内部从 0 开始计位置，下游无法通过普通读取越过 n 指定的范围。

func bodyView(data []byte, off, length int64) (*io.SectionReader, error) {
	r := bytes.NewReader(data)
	if off  r.Size() || length > r.Size()-off {
		return nil, fmt.Errorf("窗口越界: off=%d length=%d size=%d", off, length, r.Size())
	}

	// SectionReader 把底层区间封装成独立视图，保护下游解析边界。
	return io.NewSectionReader(r, off, length), nil
}

这类窗口特别适合把协议头、索引区和主体区交给不同函数：每个函数只拿到自己的读取范围，接口也更容易测试。代价是窗口内的位置和原始缓冲的绝对偏移不是同一个坐标系，日志里最好同时记录 off 和窗口内位置。

常见问题

ReadAt 会不会改变 Len？

不会。ReadAt 不推进顺序游标，因此不会因为这次读取而减少 Len；顺序调用 Read 或移动游标后，Len 才会变化。

Len 和 Size 应该怎么选？

判断“当前还能顺序读多少”用 Len；判断底层数据总范围或建立绝对边界用 Size。不要用读取后的 Len 计算原始偏移上限。

什么时候不用 SectionReader？

如果调用方本来就需要在整份数据上按绝对偏移读取，ReadAt 更直接；只有当下游必须被限制在一个区间内时，才把边界封装成 SectionReader。

把这几个概念分开后，bytes.Reader 的选择就很直观：主流程消费数据用 Read，旁路检查用 ReadAt，确实要移动主游标才用 Seek，要把权限和范围一起交给下游则用 SectionReader。缓冲视图控制的重点，从来不是多调用一个 API，而是让每个函数只看到它应该看到的字节范围。