Go io.SectionReader 读到文件尾怎么处理：偏移量、剩余长度与 EOF 判断

用 io.SectionReader 读取文件头、索引区或归档中的一段固定范围时，最容易误判的是文件尾：一次读取返回了 io.EOF，并不等于这次业务读取一定失败。真正要先确认的是已经拿到了多少字节，以及这多少字节是否达到调用方要求。

先看清 SectionReader 管的三件事

io.NewSectionReader(r, off, n) 把底层的 io.ReaderAt 包成一个有边界的读取器。off 是区间在原文件中的起点，n 是这个区间允许暴露的长度；之后调用 Read 时，读取位置从区间开头开始递增。

可以把它理解成一扇只能向前打开的窗：窗外的文件内容不会被读到，窗口内已经读过的部分也不会自动回退。判断结果时，下面三个值要放在一起看。

固定长度数据先判断 n，再处理 EOF

假设文件头声明后面紧跟 32 字节索引，业务协议要求这 32 字节必须全部存在。此时可以把读取结果收敛成一个明确的判断函数：

func readFixed(sr *io.SectionReader, want int) ([]byte, error) {
	buf := make([]byte, want)
	n, err := io.ReadFull(sr, buf)
	if err != nil {
		return buf[:n], fmt.Errorf("read %d bytes: got %d: %w", want, n, err)
	}
	return buf, nil
}

io.ReadFull 会持续读取直到填满缓冲区或遇到错误。对于固定长度协议，它比手写一次 Read 更稳，因为一次 Read 即使没有报错，也不保证把整个缓冲区填满。

如果坚持直接调用 Read，核心判断至少应当写成：

n, err := sr.Read(buf)
switch {
case n == len(buf):
	// 数据长度满足协议；err 只需按底层语义记录或继续审查
case err != nil:
	return fmt.Errorf("section is incomplete: got %d/%d: %w", n, len(buf), err)
default:
	return fmt.Errorf("short read: got %d/%d", n, len(buf))
}

这里的重点是顺序：业务完整性由 n 决定，错误类型由 err 补充说明。把 err == io.EOF 写成唯一失败条件，会漏掉短读但暂时没有错误的情况；把 err == nil 写成唯一成功条件，也会把某些已读满的边界结果误判。

读到区间末尾时，短读和正常结束不是一回事

对日志尾部、可选扩展块或流式索引来说，读到当前区间末尾可能就是正常结束。这类代码不应强行把 EOF 变成“数据损坏”，而要明确业务允许的最小长度：

func readUntilEnd(sr *io.SectionReader) ([]byte, error) {
	var out bytes.Buffer
	tmp := make([]byte, 64)
	for {
		n, err := sr.Read(tmp)
		if n > 0 {
			out.Write(tmp[:n])
		}
		if err == io.EOF {
			return out.Bytes(), nil
		}
		if err != nil {
			return nil, err
		}
	}
}

这个循环保留了 n > 0 的数据，再判断错误；不能因为这一轮带有 EOF 就丢掉同一轮已经返回的字节。若业务还要求“至少读到 1 个完整记录”，应在返回前另外检查记录边界，而不是把所有 EOF 都放行。

为什么随机偏移读取要换成 ReadAt

SectionReader 同时提供 ReadAt。当程序要读取文件头、目录项和多个索引位置时，调用 Read 后再手工回退位置很容易把状态弄乱；ReadAt 则把偏移量直接放在调用参数里，不改变当前读取位置。

func readEntry(sr *io.SectionReader, offset int64) ([]byte, error) {
	buf := make([]byte, 24)
	n, err := sr.ReadAt(buf, offset)
	if n != len(buf) {
		return buf[:n], fmt.Errorf("entry at %d is incomplete: %d/%d: %w", offset, n, len(buf), err)
	}
	if err != nil && !errors.Is(err, io.EOF) {
		return nil, err
	}
	return buf, nil
}

ReadAt 的 offset 是相对于 SectionReader 区间起点的偏移，不是原文件的绝对偏移。这个细节适合写进测试：给区间设置一个非零起点，再验证 ReadAt(sr, 0) 读到的是区间首字节。

一组可复查的边界测试

不要只测“文件足够长”的成功用例。至少覆盖区间刚好够、少一个字节、偏移超出区间三种情况：

func TestSectionReaderBoundary(t *testing.T) {
	src := strings.NewReader("header|payload")
	sr := io.NewSectionReader(src, 7, 7) // payload

	buf := make([]byte, 7)
	n, err := sr.ReadAt(buf, 0)
	if n != 7 || err != nil {
		t.Fatalf("full section: n=%d err=%v", n, err)
	}

	n, err = sr.ReadAt(make([]byte, 8), 0)
	if n != 7 || !errors.Is(err, io.EOF) {
		t.Fatalf("short section: n=%d err=%v", n, err)
	}
}

测试的断言同时检查字节数和错误值，能够避免实现换成另一种合法的 ReaderAt 后，测试只盯着错误字符串而失去意义。

相关问题

SectionReader 的 Read 返回 EOF 时，数据还能用吗？

看 n 和业务协议。如果已经拿满所需字节，EOF 可能只是边界提示；如果没有拿满固定长度数据，就应按不完整处理。

为什么不直接对 SectionReader 调用 io.ReadAll？

允许读完整个区间且内存预算明确时可以用；固定长度协议仍建议显式校验结果长度，避免把截断内容当成有效记录。

Read 和 ReadAt 的 offset 有什么区别？

Read 使用并推进共享当前位置；ReadAt 使用相对区间起点的偏移量，不推进当前位置，更适合随机访问和并行读取。

最后留一条判断规则

把 SectionReader 当作有边界的窗口：固定长度数据先核对 n，可变长度数据保留已读字节后再处理 EOF，随机偏移则使用 ReadAt。这三条分开写进代码，文件尾就不会再靠猜。