Go os.File.ReadAt 返回 io.EOF 仍有数据时怎么处理

用 os.File.ReadAt 读取文件尾部时，看到 n > 0 同时 err == io.EOF 不必马上丢弃数据。判断重点是 n 是否已经等于请求缓冲区长度：读满了，EOF 只是在说明读取位置碰到了文件末尾；没有读满，EOF 才表示这次请求缺少后续字节。调用方应先处理 buf[:n]，再按照业务是否允许短数据做决定。

ReadAt 为什么会出现“有数据又是 EOF”

os.File.ReadAt 按给定偏移读取 len(buf) 个字节，并返回 n 和 err。它和普通 Read 的一个重要区别是：请求没有读满时必须返回非空错误。文件剩余字节刚好填满缓冲区时，io.ReaderAt 契约允许实现返回 io.EOF 或 nil；因此不能把 EOF 简化成“一个字节也没读到”。

先记住这张判断表：

处理顺序应该是先看 n，再处理 err

最容易出现的数据丢失写法是先判断 err != nil 就直接返回。正确顺序是先确认 n > 0，只把 buf[:n] 交给解析器或写入下游；然后再判定错误。下面的辅助函数适合“必须拿到完整固定长度数据”的场景：

package reader

import (
    "io"
    "os"
)

func readBlock(f *os.File, off int64, size int) ([]byte, error) {
    // 缓冲区长度代表调用方要求的完整记录大小。
    buf := make([]byte, size)
    n, err := f.ReadAt(buf, off)

    // 只有已经读到的前缀属于本次有效输入。
    if n == len(buf) {
        // 读满时 EOF 只表示同时抵达文件末尾，不丢弃完整块。
        return buf, nil
    }
    if n > 0 {
        // 固定长度记录不能拿不完整前缀冒充完整数据。
        _ = buf[:n]
    }
    if err == io.EOF {
        // 文件尾部缺少字节，向上层表达“结构不完整”。
        return nil, io.ErrUnexpectedEOF
    }
    if err != nil {
        // 其他 I/O 错误保留原始错误，便于调用方定位。
        return nil, err
    }
    // ReaderAt 短读应带错误，这里是防御性分支。
    return nil, io.ErrUnexpectedEOF
}

这个函数没有因为 io.EOF 就重试。普通文件在同一个偏移上重试不会凭空产生缺失字节，反而可能让上层把短记录误判成暂时故障。若业务允许最后一段不足一个块，则不要调用这个固定长度 helper，而是保留 buf[:n] 作为尾部数据，并把 EOF 作为“读取结束”记录。

固定块、可变尾部和并发读取怎么选错误策略

错误是否要上抛，取决于文件格式的边界，而不是 EOF 这个名字本身。

• 固定记录：例如每条索引项固定 64 字节，n 说明记录损坏或文件被截断，应返回 io.ErrUnexpectedEOF，让调用方停止解析。
• 可变尾部：如果最后一段允许不足一个块，先解析 buf[:n]，记录文件结束即可；不要强行填充零字节。
• 偏移读取：off 使用 int64，调用前确认不是负数，并避免计算偏移时发生整数溢出。
• 并发读取：官方文档说明同一输入源上的多个 ReadAt 可以并行执行；每个调用仍要独立处理自己的 n 和 err，不要共享可变缓冲区。

这里的核心取舍是“格式完整性”与“尽可能保留尾部数据”：协议、索引和定长二进制结构优先保证完整；日志、分片或可恢复文本则可以保存有效前缀，再把 EOF 作为结束信号。

常见问题

n 大于 0 时能不能直接忽略所有错误？

不能。只有在确认 n == len(buf) 且错误是文件尾部的 io.EOF 时，才通常把它视为完整读取；其他错误仍应返回或记录。

ReadAt 返回 EOF 后再读一次能得到剩余数据吗？

如果本次已经短读到文件末尾，普通文件没有更多数据可读；应处理已返回的前缀并根据格式决定结束或报 io.ErrUnexpectedEOF，而不是无条件循环。

为什么不直接用 os.ReadFile？

os.ReadFile 适合一次取得整个文件内容；需要按偏移读取、控制内存或并行处理固定区块时，ReadAt 的返回契约更合适。

记忆这一条就够了：ReadAt 的错误不能替代字节数判断。先处理 n > 0 的有效数据，再用 n == len(buf)、文件格式和错误类型共同决定下一步。