Go os.File.ReadAt 并发读文件为什么不互相改偏移：ReaderAt、SectionReader 与验收

做大文件分片校验时，最容易踩到的坑不是 goroutine 数量，而是把同一个 *os.File 当成普通 io.Reader，让多个任务一起调用 Seek 和 Read。共享偏移量一旦被改写，读到的分片就不再由任务自己决定。Go 的 ReadAt 把偏移量放进了调用参数，正好可以把“谁读哪一段”固定下来。

先复现：Seek 加 Read 为什么会读乱分片

假设文件里按顺序写入 chunk-0、chunk-1、chunk-2，每个任务先定位再读取：

func readChunk(f *os.File, off int64, size int) ([]byte, error) {
    if _, err := f.Seek(off, io.SeekStart); err != nil {
        return nil, err
    }
    buf := make([]byte, size)
    _, err := io.ReadFull(f, buf)
    return buf, err
}

单线程调用时，这段代码看起来没有问题。并发后，任务 A 刚把游标移到 0，任务 B 可能已经把游标移到 1024；A 接下来的 ReadFull 读到的就未必是自己的区间。加互斥锁可以让它正确，但读操作会退化成串行队列。

这里的判断信号很明确：同一个文件、多个 goroutine、每个任务都有独立偏移，且结果偶尔错位。先别急着增加锁，应该先把“偏移状态”从文件对象里拿出来。

ReadAt 的关键边界：偏移属于调用，不属于文件游标

io.ReaderAt 的契约是从给定偏移读取数据，调用不应影响底层 seek offset；官方文档也明确允许对同一个输入源并行调用 ReadAt。*os.File 实现了这个接口，因此分片任务可以这样写：

func readChunkAt(f *os.File, off int64, size int) ([]byte, error) {
    buf := make([]byte, size)
    n, err := f.ReadAt(buf, off)
    if err != nil {
        if err == io.EOF && n == len(buf) {
            return buf, nil
        }
        return nil, fmt.Errorf("read offset %d: %w", off, err)
    }
    if n != len(buf) {
        return nil, fmt.Errorf("short read at %d: got %d want %d", off, n, len(buf))
    }
    return buf, nil
}

当完整读取恰好落在文件尾部时，具体实现可能返回 n == len(buf) 且错误为 nil，也可能返回 io.EOF。因此验收条件应先看 n 是否满足，再按“完整读到尾部”的规则处理 EOF。真正的短读则不能悄悄放过。

固定区间用 SectionReader，把范围约束写进类型

如果一个任务只允许读取文件的某一段，可以把文件包装成 io.SectionReader。它的相对偏移从 0 开始，超过区间末端时不会继续读到下一段：

func readSection(f *os.File, start, length int64) ([]byte, error) {
    section := io.NewSectionReader(f, start, length)
    buf := make([]byte, length)
    n, err := io.ReadFull(section, buf)
    if err != nil {
        return nil, fmt.Errorf("section start=%d length=%d: %w", start, length, err)
    }
    if int64(n) != length {
        return nil, fmt.Errorf("section short read: got %d want %d", n, length)
    }
    return buf, nil
}

这里的分工是：ReadAt 适合任务已经知道绝对偏移的随机读取；SectionReader 适合把“本任务只能看到这段数据”作为边界传递给下层解析器。两者都不会通过共享文件游标协调读取。

并发分片的处理步骤：先收集结果，再按序合并

并发完成顺序和文件原始顺序不是一回事。每个任务应携带自己的索引和偏移，结果回收时按索引写入固定槽位，不要按完成先后直接 append：

type chunkResult struct {
    index int
    data  []byte
    err   error
}

func readAllChunks(f *os.File, chunkSize, count int) ([][]byte, error) {
    results := make([][]byte, count)
    ch := make(chan chunkResult, count)
    for i := 0; i 

示例里的 range count 适用于支持整数 range 的 Go 版本；如果项目需要兼容更早版本，改成普通计数循环即可。生产代码还应加上取消信号、并发上限和 goroutine 退出路径，避免一个坏文件让所有任务永久等待。

反向验证：四个检查点能抓住大多数错读

1. 准备带有明显分片标识的测试文件，让每个区间的首尾内容都可识别。
2. 重复运行不同任务数的并发读取，确认每个结果槽位仍对应原始索引。
3. 把最后一个分片改成不足整块的文件，确认返回短读错误，而不是补零后当成功。
4. 开启 go test -race，重点观察结果缓冲区是否被多个任务复用或写入。

如果只是把 Seek + Read 换成 ReadAt，但仍然把同一个可变 byte slice 交给多个 goroutine，数据仍可能互相覆盖。文件偏移安全不等于结果缓冲区安全，这两个问题要分开验收。

常见问题

ReadAt 读到文件末尾一定会返回 EOF 吗？

不一定。若刚好读满缓冲区，允许返回完整字节数并把错误留空，也允许带 EOF；代码应以字节数和实际边界共同判断。

ReadAt 和 ReadAtLeast 适合解决同一件事吗？

不完全相同。ReadAt 负责“从哪个偏移读”，ReadAtLeast 负责“至少读够多少”，组合使用前要先确认底层对象是否提供稳定的定位语义。

多个 goroutine 可以共享一个 *os.File 吗？

使用 ReadAt 或 SectionReader 做独立范围读取时通常可以；如果混用 Seek、Read、Write，仍需要明确所有权或同步规则。

SectionReader 会把数据复制到新文件吗？

不会。它只是给已有 ReaderAt 加上起点和长度边界，读取时仍访问原始数据源。

把判断写进代码，分片读取才容易维护

这类代码的稳定性不在于“开了多少个 goroutine”，而在于三个边界是否显式：任务的绝对偏移、任务允许读取的长度、短读和 EOF 的处理方式。绝对定位选 ReadAt，范围隔离选 SectionReader，结果合并按索引落位；最后用竞态检测和文件尾部用例做反向确认，后续改动才不会悄悄把并发读取变回共享游标。