Go io.SectionReader 读到区间末尾时怎么判断数据是否完整

我在处理分片文件时，最容易把 io.EOF 看成“读取失败”。但 io.SectionReader 的 EOF 还可能只是说明本次请求碰到了人为设定的区间末尾。判断数据是否完整，不能只看 err，而要同时看 n、目标缓冲区长度和 section 的剩余大小。

先把 SectionReader 看成一段独立地址空间

io.NewSectionReader(r, off, n) 从底层 ReaderAt 的 off 开始，向外暴露长度为 n 的逻辑区间。调用方传给 ReadAt 的偏移是相对区间起点的，不是底层文件的绝对偏移。

因此，完整性判断的第一步不是猜 EOF 的含义，而是先算清“本次请求在区间里还有多少空间”。Size() 返回创建时设定的区间长度；它不会因为已经调用过 Read 而变小。

Read 的 EOF 要结合 n 一起处理

Read 维护内部游标，读到区间末尾后，下一次调用会返回 0, io.EOF。如果本次调用先读到了最后一小段，调用方仍应先消费这段数据；不能因为同时看到 EOF 就丢掉 n 个字节。

package main

import (
    "fmt"
    "io"
    "strings"
)

func readSectionSequentially(src io.ReaderAt, start, size int64) ([]byte, error) {
    section := io.NewSectionReader(src, start, size)
    buf := make([]byte, 3)
    var out []byte

    for {
        n, err := section.Read(buf)
        // 先追加已经读到的字节；n 大于零时不能因 EOF 丢掉尾部数据。
        out = append(out, buf[:n]...)
        if err == io.EOF {
            // EOF 只表示 section 没有更多数据，已读内容仍然有效。
            return out, nil
        }
        if err != nil {
            // 其他错误需要保留，不能把所有错误都降级成正常结束。
            return nil, err
        }
    }
}

func main() {
    data := strings.NewReader("header|payload|tail")
    got, err := readSectionSequentially(data, 7, 7)
    // 这里只展示调用结果，实际项目中应按业务处理 got。
    fmt.Printf("%q %v\n", got, err)
}

这个循环的关键是“先处理 n，再处理 err”。对于实现良好的 Reader，n > 0 与非空错误可以同时出现，所以只写成 if err != nil { return err } 会漏掉最后一段数据。

ReadAt 判断完整性时，优先比较 n 和 len(p)

ReadAt 不移动 SectionReader 的顺序读取游标，更适合读取文件头、索引块或分片中的固定位置。它的契约比 Read 更严格：当没有足够数据填满 p 时，返回的 n 会小于 len(p)，并带有非空错误。

对 SectionReader 来说，如果请求长度越过区间末尾，内部会把请求裁剪到剩余空间；底层读取成功后，包装层会把错误补成 io.EOF。这代表“数据只够到 section 末尾”，不代表缓冲区已经完整填满。

package main

import (
    "errors"
    "fmt"
    "io"
    "strings"
)

func readExactFromSection(src io.ReaderAt, start, size, relative int64, want int) ([]byte, error) {
    if want = size {
        // 相对偏移不在 section 内时，不创建容易误判的空结果。
        return nil, fmt.Errorf("invalid section range")
    }
    p := make([]byte, want)
    n, err := io.NewSectionReader(src, start, size).ReadAt(p, relative)
    // 固定长度读取先看 n；只有填满目标缓冲区，数据才算完整。
    if n != len(p) {
        if errors.Is(err, io.EOF) {
            return nil, io.ErrUnexpectedEOF
        }
        if err != nil {
            return nil, err
        }
        return nil, io.ErrUnexpectedEOF
    }
    if err != nil && !errors.Is(err, io.EOF) {
        // 完整数据仍可能伴随底层错误，非 EOF 错误不能吞掉。
        return nil, err
    }
    return p, nil
}

func main() {
    src := strings.NewReader("0123456789")
    got, err := readExactFromSection(src, 2, 5, 2, 3)
    // want=3 且区间还剩 3 字节时，got 才是完整的固定块。
    fmt.Printf("%q %v\n", got, err)
}

示例把“部分数据到达区间末尾”转换为 io.ErrUnexpectedEOF，这样上层更容易区分“正常顺序读完”和“固定长度记录被截断”。如果业务允许短块，则可以返回 p[:n] 和一个单独的状态，而不是强制报错。

四种边界情况可以这样速查

还有一个容易忽略的细节：如果请求的缓冲区长度是零，不能把“没有读取字节”直接等同于截断。固定长度读取函数最好在入口明确约定零长度是否是合法输入，并在业务层单独处理。

常见问题

看到 io.EOF 是否一定要返回失败？

不一定。顺序读取中，n == 0 && err == io.EOF 通常表示自然结束；固定长度读取中，若 n ，则应按业务把它视为不完整。

ReadAt 返回 n == len(p) 还能有 EOF 吗？

底层 ReaderAt 在刚好读到输入末尾时允许返回 io.EOF 或 nil。因此判断完整性首先看 n，再把非 EOF 的错误继续向上返回。

为什么不用 Size() 减去当前游标判断 ReadAt？

ReadAt 的偏移是独立参数，不依赖顺序读取游标。应该比较 relative、len(p) 和 Size()，不要把两种读取模型混在一起。

什么时候使用 io.ReadFull？

当你要从一个顺序 io.Reader 读取固定长度时，io.ReadFull 能直接把短读转换为 io.ErrUnexpectedEOF。但对 ReaderAt 的随机偏移读取，仍需自己根据 n 和 err 做判断。

记住一条足够实用的规则：顺序读取先处理 n 再处理 EOF，固定偏移读取先比较 n 与目标长度。这样就不会把区间尾部的正常边界和真正的截断混为一谈。