Go os.File.Close 为什么关闭后重复读取返回不同错误

os.File.Close 关闭的是文件句柄，不会让它变成一个“已经读到末尾”的文件。关闭后再直接对这个文件做 I/O，应按已关闭资源处理；如果几次读取看到了 EOF、已关闭错误，甚至先读到数据，首先要确认调用的是原始 *os.File，还是包在外面的 bufio.Reader，以及错误是否又被业务层包装。不能把这些现象理解成 Close 随机选择错误。

我的排查顺序会先看读取对象与关闭归属，再看错误文本。下面用一个导入任务的假设场景拆解：辅助函数打开文件后返回 Reader，却在返回时 defer Close，导致真正消费数据的代码拿到已失效的资源。这是说明场景，示例没有在本文生成过程中执行。

Go 官方地址：https://go.dev/

先看影响面：导入任务读到的到底是哪一层

假设导入器只接受 io.Reader，上游给它的可能是文件、缓冲读取器或带长度限制的 Reader。接口相同，不代表状态相同。直接的文件读取依赖打开的句柄；bufio.Reader 还持有已经读入内存的数据；io.LimitReader 则会在到达自身限制后报告 EOF。这些包装都值得在排查时记下来。

文件读到末尾通常得到 EOF，它描述当前读取位置的结束。关闭描述资源生命周期结束。重复 Close 本身也返回错误，所以同时记录第二次 Close 和之后 Read 的错误，会产生不同操作名的日志；这不代表同一次读取的底层状态发生了神秘变化。

把时间线拆开：在关闭点记录操作与错误类别

先用一个独立的临时文件确认“关闭以后直接读取”的含义。这里使用非空读取缓冲区，避免把零长度读取的边界混入问题。只针对自己创建的临时文件操作，不需要修改业务数据。

package main

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

func report(op string, err error) {
    // 分类看错误链，不依赖路径或平台相关的字符串。
    fmt.Printf("%s: closed=%v eof=%v err=%v\n",
        op, errors.Is(err, os.ErrClosed), errors.Is(err, io.EOF), err)
}

func main() {
    f, err := os.CreateTemp("", "reader-lifecycle-*.txt")
    if err != nil {
        report("create", err)
        return
    }
    name := f.Name()
    defer os.Remove(name) // 函数结束时清理本示例的临时文件。
    report("close", f.Close())
    buf := make([]byte, 8)
    for i := 0; i 

这个例子关注的是 errors.Is(err, os.ErrClosed) 的分类，而不是某个操作系统上完整错误字符串长什么样。关闭后的直接读取不应该当作正常 EOF 结束业务。如果相同对象在没有包装、没有重新赋值且没有并发操作时表现不符合预期，应保留 Go 版本、操作系统、实际调用和完整错误链，再缩小复现范围。

根因之一：外层缓冲还存在，内层文件却已经关闭

bufio.Reader 的预读会把一部分数据留在自己的内存里。文件关闭不会倒过来清空这些字节，因此继续读取包装器可能先消耗缓存，等需要触碰底层文件时才暴露关闭错误。它也可能已保存此前读取产生的结束错误。不能仅凭“关闭后还能读到几个字节”推断文件没有关闭。

func bufferedExample(f *os.File) error {
    r := bufio.NewReader(f)
    // 预读而不消费；调用方须传入已打开且位置合适的文件。
    if _, err := r.Peek(1); err != nil {
        return fmt.Errorf("预读: %w", err)
    }
    cached := r.Buffered()
    if err := f.Close(); err != nil {
        return fmt.Errorf("关闭: %w", err)
    }
    data := make([]byte, cached)
    // 只取当时已在缓冲区的字节，不把成功等同于底层文件仍可用。
    if _, err := io.ReadFull(r, data); err != nil {
        return fmt.Errorf("读取已有缓冲: %w", err)
    }
    one := make([]byte, 1)
    _, err := r.Read(one)
    return err // 后续错误取决于包装器保存的状态和底层读取。
}

这是函数片段，需要导入 bufio、fmt、io、os。它为了说明生命周期特意在中途关闭参数文件，调用方不能再把该文件交给其他消费者。真实业务的修复方向是延长文件有效期，而不是依赖预读的缓存刚好覆盖全部内容。

根因之二：返回 Reader 的函数提前关闭了文件

一个常见的所有权错误，是在创建函数中 defer f.Close()，然后把 f 作为 io.Reader 返回。defer 会在创建函数返回前执行，消费方从一开始就没有有效句柄。外层是否加缓冲只会改变症状出现的位置。把文件赋给另一个变量或接口也不会复制句柄的生命周期。

对于只需要完整内容的小文件，让打开、读取、关闭留在同一个函数里，返回独立的字节数据通常更容易解释。下面把“读取失败”和“关闭失败”都保留下来，不会让关闭错误掩盖先前读取错误。

func loadImport(path string) ([]byte, error) {
    f, err := os.Open(path)
    if err != nil {
        return nil, fmt.Errorf("打开导入文件: %w", err)
    }
    // 本函数独占文件生命周期；返回数据，不返回已关闭的 Reader。
    data, readErr := io.ReadAll(f)
    closeErr := f.Close()
    if readErr != nil {
        if closeErr != nil {
            return nil, errors.Join(
                fmt.Errorf("读取导入文件: %w", readErr),
                fmt.Errorf("关闭导入文件: %w", closeErr),
            )
        }
        return nil, fmt.Errorf("读取导入文件: %w", readErr)
    }
    if closeErr != nil {
        return nil, fmt.Errorf("关闭导入文件: %w", closeErr)
    }
    return data, nil
}

这个函数片段需要 errors、fmt、io、os，errors.Join 要求 Go 1.20 或更新版本。io.ReadAll 适合内容规模可控的文件；大文件应在拥有文件的函数内流式处理，或者明确把 io.ReadCloser 交给消费方，并约定由消费方在使用完成后关闭。不要把大型文件全部读入内存只为了躲开所有权问题。

防止复发：错误分类与资源归属一起修

日志中保留操作名、错误类型和必要的任务标识，避免在公开日志暴露敏感路径。对一般 io.Reader，必须先处理 n 大于零的数据，再处理错误；一次读取可能同时交回数据和错误。读循环不能只要 err 非 nil 就直接丢弃本次已经读到的内容。

os.File 的方法可以并发调用，不意味着业务可以一边关闭一边期待另一个 goroutine 一定读完。关闭时间仍应由清晰的拥有者决定，生产方、消费方及清理逻辑之间要有明确的完成约定。重复对同一个已关闭文件读取，也不会让它恢复；确实需要重新读取时，重新打开文件或在关闭前管理读取位置。

相关问题

第二次 Close 的错误可以一律忽略吗？

文档明确它会返回错误。应先确保业务只存在一个关闭责任方，区分清理阶段的重复关闭与首次关闭失败，不要用“反正能重复调用”掩盖归属混乱。

为什么不比较 err.Error()？

文本可能包含操作名、文件路径和包装信息。用 errors.Is 检查已知错误更合适；需要路径错误的结构化字段时再使用 errors.As。

Seek 能让已关闭的文件恢复吗？

不能。Seek 调整的是有效文件的偏移位置，不会重新打开已经关闭的句柄。需要新的生命周期时应重新 Open。

参考：os.File.Close 和文件错误、bufio.Reader、io.Reader 读取约定、errors.Join。