Go os.File.ReadAt 如何处理短读：偏移量、EOF 与完整读取

把日志文件按固定偏移切成小块时，os.File.ReadAt 很顺手：每个调用都明确给出起始字节位置，不依赖共享读取游标。真正容易出错的是短读——缓冲区没有填满时，返回值里的 n 和 err 必须一起看，不能只判断有没有拿到数据。

ReadAt 的核心规则是：从指定偏移读取，返回实际字节数；只要 n ，就必须有非空错误，读到文件尾通常是 io.EOF。

固定偏移读取解决了什么问题

File.Read 会从当前文件位置继续读，多个读取者共用一个文件句柄时，调用顺序会影响结果。File.ReadAt 则把位置写在参数里。下面的 readChunk 每次从传入的 offset 读取，调用者可以明确知道这段数据属于文件的哪一块。

package main

import (
    "fmt"
    "io"
    "os"
)

func readChunk(file *os.File, offset int64, size int) ([]byte, error) {
    buf := make([]byte, size)
    n, err := file.ReadAt(buf, offset)
    if n > 0 {
        buf = buf[:n]
    }
    if err != nil && err != io.EOF {
        return nil, err
    }
    return buf, err
}

func main() {
    file, err := os.Open("sample.log")
    if err != nil {
        panic(err)
    }
    defer file.Close()

    payload, err := readChunk(file, 32, 16)
    fmt.Printf("payload=%q bytes=%d err=%v\n", payload, len(payload), err)
}

图中的 readChunk 只负责组织缓冲区和偏移量，真正读取由 os.File.ReadAt 完成，结果回到 payload。它不会像 Read 那样依赖文件当前游标；不过文件句柄本身仍要正确关闭。

n 和 err 要按一组结果判断

假设文件从偏移量 32 开始只剩 7 个字节，而缓冲区长度是 16。此时 ReadAt 会把前 7 个字节写进 buf，返回 n == 7 和 err == io.EOF。有效数据只能看 buf[:n]，不能把整个缓冲区交给解析器。

这条判断链比“err != nil 就丢弃数据”更准确。到文件尾的 io.EOF 和磁盘、权限等其他错误不是一回事：前者可能是最后一个合法分片，后者通常需要交给上层处理。

固定长度分片要自己推进 offset

如果协议要求每个分片必须正好 4 KiB，可以把短读当成失败；如果只是顺序扫描文件，则可以接受最后一块不足 4 KiB。关键是把 offset 推进 int64(n)，而不是固定加上缓冲区长度，否则遇到短读时会跳过数据边界。

func readAllAt(file *os.File, offset int64, size int) ([]byte, error) {
    result := make([]byte, 0, size)
    for {
        buf := make([]byte, size)
        n, err := file.ReadAt(buf, offset)
        result = append(result, buf[:n]...)
        offset += int64(n)

        if err == io.EOF {
            return result, nil
        }
        if err != nil {
            return nil, err
        }
        if n == 0 {
            return result, nil
        }
    }
}

这个循环把“实际消费了多少字节”作为下一轮位置。生产代码还应限制最大文件大小，并根据业务协议决定最后的半块是正常结束还是格式错误。

并发读取时仍要守住边界

io.ReaderAt 的契约允许调用方对不重叠区间并行调用。并行并不意味着可以忽略返回值：每个 goroutine 仍要独立检查自己的 n 和 err，并把结果写入属于自己的切片区域。若多个任务写同一段内存，问题就从文件偏移变成了数据竞争。

相关问题

ReadAt 返回 n 大于 0 和 io.EOF 时要不要丢数据？

通常不应直接丢弃。先处理 buf[:n]，再按文件格式判断这段尾部数据是否完整。

ReadAt 会改变 File 的当前读取位置吗？

不会。它使用传入的偏移量；如果业务还混用 Seek 与 Read，仍要单独管理共享游标的并发问题。

什么时候应该使用 io.ReadFull？

当你面对的是顺序 io.Reader，并且协议要求填满固定长度缓冲区时，io.ReadFull 更直接；随机偏移读取则继续使用 ReadAt 并检查短读。

把判断写进读取函数

可靠的分片读取不靠“碰巧读满”：记录起始偏移，使用返回的 n 截取有效数据，区分 io.EOF 与其他错误，再决定是否继续推进。把这几条规则封装在一个小函数里，后面的日志解析、文件切片和并发预读都会更容易验收。