Go os.Stat 判断存在后文件为什么仍然打不开

os.Stat 成功只表示那一次查询取得了路径对应对象的属性，不保证下一次 os.Open 仍然成功。文件可能被删除、路径可能被替换，或者当前进程虽然能够查询属性，却没有读取内容的权限。要读取文件，应直接 Open 并处理错误，不要先检查“存在”再把检查结果当作读取许可。

官方文档地址：https://pkg.go.dev/os。下面的最小写法针对可信目录中的普通小文件，不是处理任意用户路径的完整安全沙箱。

直接打开，并从句柄获取需要的属性

这个示例把成功条件收敛为：打开成功、已打开对象是普通文件、完整读取未超过上限，并且没有被忽略的读取或关闭错误。先给出完整代码，再说明它解决了什么、没有解决什么。

package main

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

func readSmall(name string) (data []byte, err error) {
    f, err := os.Open(name) // 直接执行需要的操作，不把 Stat 当成通行证
    if err != nil {
        return nil, fmt.Errorf("open input: %w", err)
    }
    defer func() {
        if closeErr := f.Close(); closeErr != nil && err == nil {
            data = nil // 不隐藏关闭失败，也不交付看似成功的内容
            err = fmt.Errorf("close input: %w", closeErr)
        }
    }()

    info, err := f.Stat() // 属性属于已经打开的对象，不再次按路径查找
    if err != nil {
        return nil, fmt.Errorf("stat opened input: %w", err)
    }
    if !info.Mode().IsRegular() {
        return nil, fmt.Errorf("input is not a regular file")
    }

    const limit = 1  limit { // 多读一个字节，避免把截断内容当完整文件
        return nil, fmt.Errorf("input exceeds size limit")
    }
    return data, nil
}

func main() {
    if len(os.Args) != 2 {
        fmt.Fprintln(os.Stderr, "usage: reader ")
        return
    }
    data, err := readSmall(os.Args[1]) // 仅用于可信目录中的普通文件
    if err != nil {
        switch {
        case errors.Is(err, fs.ErrNotExist):
            fmt.Fprintln(os.Stderr, "文件或路径组件不存在")
        case errors.Is(err, fs.ErrPermission):
            fmt.Fprintln(os.Stderr, "当前进程无权访问")
        default:
            fmt.Fprintln(os.Stderr, err) // 内部示例；对外接口应隐藏敏感路径
        }
        return
    }
    fmt.Printf("read_bytes=%d\n", len(data)) // 不打印文件正文
}

f.Stat 询问已经打开的对象，避免在取得句柄后又调用 os.Stat(name) 查到另一个路径对象。读取上限也不能只看 info.Size：其他进程可能继续修改文件。示例采用限量读取加一个额外字节来识别超限，但不提供文件内容的一致性快照，也不保证读取不会阻塞。

为什么“检查存在”和“打开成功”不是同一件事

需要保护的资产不仅是一个名字，还包括实际读取对象的身份、内容及访问权限。路径是名字查找入口；元数据是一次查询结果；文件句柄是实际操作得到的对象引用。将这三者混为一谈，才会出现“明明存在却打不开”的困惑。

例如后台任务先查到 input.txt，维护进程随后将它重命名或删除，读取任务再按相同名字打开时就可能失败。若路径允许被其他用户修改，还可能出现名字指向另一个对象的问题。这属于检查与使用之间的竞态，常称为 TOCTOU；多补一次 Stat 只会增加一次新的查询，并不会把两个系统操作合并成一个原子承诺。

即使没有并发变化，Stat 和 Open 的访问要求也不同。能查到元数据不等于能读取文件正文。路径组件权限、访问控制、服务账户、容器挂载及平台规则都可能影响结果；不要把每个错误都归为“文件不存在”。在 Unix 上尤其不能只看文件自身的权限位，还要考虑父目录的搜索权限。

普通故障和不可信目录要分开处理

不要声称“直接 Open”消除了全部文件竞态。它消除的是多余的存在性前置判断；Open 本身仍然要解释路径，也可能跟随符号链接。示例在打开后检查普通文件类型，但若输入指向 FIFO 或设备，打开动作本身就可能阻塞或带来其他行为，因此不能把它直接用于不可信目录。

创建文件和限制目录分别需要什么控制

如果任务其实是“只有不存在时才创建”，不要先 Stat 再 Create，因为 Create 可能截断已存在的文件。应使用 OpenFile 的 O_CREATE 与 O_EXCL 组合表达排他创建语义，并处理 ErrExist。这个标志也不等于完整事务，后续写入失败和清理策略仍要设计；网络文件系统还应核对其具体语义。

如果任务是“只能读取指定目录树内的文件”，支持相应 API 的 Go 环境可以考虑 os.OpenRoot 与 Root.Open。Root 对路径及符号链接的约束比简单拼接字符串更适合这个目标，但仍须阅读平台限制：它不是操作系统沙箱，不阻止所有挂载边界、设备或特殊文件访问，也不证明根目录内部的每个文件都可信。

普通字符串前缀检查不能可靠地证明路径位于允许目录；Lstat 虽然可用于观察链接本身，也不能靠“先检查再普通 Open”消除替换窗口。对于文件身份、所有者或不可变内容有强要求的服务，还需结合平台能力、目录权限和可信生产流程，不能只比较一次大小或修改时间。

记录操作错误，而不是继续记录旧的存在状态

错误记录至少应区分操作阶段和类别，例如打开失败、句柄属性读取失败、正文读取失败或大小超限。errors.Is 可穿透本例的 %w 包装，分别匹配 fs.ErrNotExist 和 fs.ErrPermission；其他错误保留原始原因供内部定位。os.Stat 返回任何错误时都归为不存在，会掩盖真正的权限或 I/O 故障。

对外接口不要原样返回包含敏感路径的错误。内部日志也应控制路径与文件内容的暴露范围。若确实要记录 PathError，可按需要提取 Op 和受控错误类别，不要为了排障把整份文件正文写入日志。

读者可以将代码保存为 main.go，在自己控制的测试目录运行以下命令。本文未执行这些示例，也不将预期行为当作运行证据。

go run main.go ./sample.txt # 指向自己准备的可信普通小文件
go run main.go ./missing-demo.txt # 事先确认该测试文件不存在，观察错误分支

普通小文件预期输出 read_bytes 的字节数；不存在的测试路径应进入不存在分支。权限结果依账户、系统和文件系统而变，不要用高权限进程测试后就断言普通服务也能读取。代码只是便于观察的示例，不演示更改权限或构造攻击目录。

两个容易反复绕回去的问题

再重试一次 Stat 能解决吗？不能提供保证。重试只适用于已明确可恢复的临时故障，并应有次数、等待和最终错误策略；权限错误不应靠无限重试处理。

打开后就能读到固定不变的内容吗？不能。句柄避免后续按同名路径重新选择对象，但其他写入者仍可能改变内容，具体行为与平台有关。要一致快照，应由文件生产与消费协议或底层存储机制提供，而不是由 Stat 推断。

因此，存在性查询适合展示状态，不适合作为未来操作的保证。把业务成功条件放到真正的 Open、Read 和 Close 上，再根据路径可信度补上目录与资源控制，才能同时解释故障和约束风险。

参考：os.Stat、os.Open、os.Root 的约束与平台限制。