Go os.File 读写为什么出现 EOF：文件偏移、ReadAt 与游标复位

排查文件导入时，最容易让人误判的一行日志是 read config: EOF。文件明明刚写入了内容，紧接着用同一个 *os.File 读取却像空文件一样。多数情况下，磁盘上的字节并没有消失，只是文件偏移已经停在写入末尾，下一次顺序读取自然得到 io.EOF。

先看清楚：EOF 反映的是当前位置

os.File 同时实现了 io.Reader、io.Writer 和 io.Seeker。其中 Read 与 Write 共用一个文件偏移。下面这段代码先写入 11 个字节，再从同一个句柄顺序读取：

package main

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

func main() {
    f, err := os.CreateTemp("", "offset-demo-*.txt")
    if err != nil { panic(err) }
    defer os.Remove(f.Name())
    defer f.Close()

    if _, err = f.WriteString("hello world"); err != nil {
        panic(err)
    }

    buf := make([]byte, 32)
    n, err := f.Read(buf)
    fmt.Printf("n=%d err=%v\n", n, err)
    _ = io.EOF
}

输出通常是 n=0 err=EOF。写入成功后偏移在 11，读取从 11 开始，文件尾部没有可读字节。先别急着怀疑 WriteString 没落盘，查看当前位置就能验证判断：

pos, err := f.Seek(0, io.SeekCurrent)
fmt.Printf("offset=%d err=%v\n", pos, err)

三种读取方式，差别在于谁负责移动游标

同一个文件可以用顺序读取，也可以用定位读取。选择时只要盯住“是否改变共享偏移”这一点：

需要连续读，就显式复位

写入完成后把偏移移回起点，再使用普通 Read：

if _, err := f.Seek(0, io.SeekStart); err != nil {
    panic(err)
}

n, err := f.Read(buf)
if err != nil && err != io.EOF {
    panic(err)
}
fmt.Printf("content=%q bytes=%d\n", buf[:n], n)

这里的检查顺序很重要：Read 可能同时返回有效字节和 io.EOF，不要因为看到 EOF 就丢掉 n 个字节。更稳妥的循环应先处理 n>0，再判断错误。

只读固定区段，就用 ReadAt

ReadAt 把起点作为参数传入，不依赖当前游标。例如读取文件开头 5 个字节：

header := make([]byte, 5)
n, err := f.ReadAt(header, 0)
if err != nil && err != io.EOF {
    panic(err)
}
fmt.Printf("header=%q bytes=%d\n", header[:n], n)

当目标区段不足缓冲区长度时，ReadAt 可能返回 n>0 和 io.EOF。这代表“读到文件尾”，不是“一个字节都没读到”。

文件偏移相关的三个常见误区

把 EOF 当成文件为空

先用 Stat 查看文件大小，再结合当前偏移判断：

info, err := f.Stat()
if err != nil { panic(err) }
pos, err := f.Seek(0, io.SeekCurrent)
if err != nil { panic(err) }
fmt.Printf("size=%d offset=%d\n", info.Size(), pos)

如果 size>0 且 offset==size，读到 EOF 就是正常的游标结果。

以为重新调用 Read 会自动回到开头

不会。Read 是有状态的顺序读取，下一次从上一次结束的位置继续。需要从头开始时，明确调用 Seek；如果多个函数都能操作同一个句柄，最好把“谁负责复位”写在函数契约里。

多个 goroutine 共享一个 File 做定位读取

ReadAt 不改变偏移，通常比多个 goroutine 交替 Seek + Read 更容易推理。但它仍然要面对文件是否在增长、区段是否重叠以及关闭时机等问题；“不改游标”不等于自动解决所有并发协调。

一份够用的排查顺序

1. 记录调用顺序：最后一次 Write、Seek、Read 分别发生在哪里。
2. 用 Stat().Size() 和 Seek(0, io.SeekCurrent) 同时记录文件长度与当前位置。
3. 顺序读取场景先 Seek(0, io.SeekStart)，固定区段场景改用 ReadAt。
4. 检查返回值中的 n，即使 err==io.EOF 也不要直接丢弃已经读取的数据。
5. 给“读取完成”和“读取失败”分开打日志，避免把正常文件尾误报成业务异常。

相关问题

调用 Seek 会清空文件内容吗？

不会。Seek 只移动读写位置；清空文件通常涉及截断操作，二者不是一回事。

Read 返回 n>0 和 EOF 时应该怎么处理？

先处理前 n 个字节，再把 EOF 当作“本次已经到文件尾”的结束信号。不要只看错误值。

什么时候应该重新打开文件？

如果函数边界希望每次从头读取，重新打开是简单选择；如果句柄已经在调用链中传递，复位或使用 ReadAt 通常更直接。

把 EOF 放回它真正的语义

Go 文件读取中的 EOF 不是一句“文件不存在”的结论，而是当前读取位置已经没有更多字节。先辨认 Read 是否推进了共享偏移，再决定用 Seek 复位还是用 ReadAt 定位，最后结合 n、文件大小和关闭时机核对结果，通常就能把这类误判快速收口。