Go os 怎样区分文件不存在和权限拒绝

打开文件失败时，最稳妥的区分方式是用 errors.Is 检查 fs.ErrNotExist 和 fs.ErrPermission，不要从错误字符串里查找“不存在”或“permission denied”。这样即使错误外面包了一层 *os.PathError，分类仍然可以沿着错误链工作。

先看错误分类的正确入口

os.Open、os.Stat 等文件 API 返回的错误通常带有操作和路径上下文。分类时要关心的是错误是否代表某个标准错误值，而不是 err.Error() 生成的展示文本。

io/fs 提供了跨文件系统使用的 fs.ErrNotExist 和 fs.ErrPermission。标准库文档也明确建议新代码通过 errors.Is 判断这两类错误；os.IsNotExist 和 os.IsPermission 是更早的便捷谓词。

用 errors.Is 区分不存在与权限拒绝

把分类集中在一个小函数里，调用方就不必重复判断，也不会因为换了文件 API 就改变业务分支。下面的例子把“找不到文件”和“没有权限”分开，其余错误继续保留原始信息。

package main

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

// classifyOpenError 只负责把文件打开错误映射成业务可用的类别。
func classifyOpenError(path string) string {
    _, err := os.Open(path)
    if err == nil {
        return "ok"
    }

    // errors.Is 会沿着包装链查找标准错误值，不能用字符串比较代替。
    switch {
    case errors.Is(err, fs.ErrNotExist):
        return "not-found"
    case errors.Is(err, fs.ErrPermission):
        return "permission-denied"
    default:
        // 其它错误仍返回操作和路径上下文，便于日志定位。
        var pathErr *os.PathError
        if errors.As(err, &pathErr) {
            return fmt.Sprintf("other: op=%s path=%s err=%v", pathErr.Op, pathErr.Path, pathErr.Err)
        }
        return fmt.Sprintf("other: %v", err)
    }
}

func main() {
    fmt.Println(classifyOpenError("config/app.yaml"))
}

这里的关键不是返回字符串本身，而是两个 errors.Is 分支：文件路径不存在时走 fs.ErrNotExist，访问被拒绝时走 fs.ErrPermission。如果底层返回的是其它 I/O 错误，程序不会把它错误地归入“文件不存在”。

保留 PathError 的操作与路径上下文

分类成功后仍然不要丢掉原始错误。*os.PathError 会记录操作名、路径和底层错误，适合写入结构化日志；例如 open、stat 和 remove 失败时，操作名能帮助排查“路径不存在”究竟发生在哪一步。

func explainFileError(err error) string {
    // 先分类，再尝试取出 PathError，两个动作互不替代。
    switch {
    case errors.Is(err, fs.ErrNotExist):
        return "文件不存在"
    case errors.Is(err, fs.ErrPermission):
        return "权限被拒绝"
    }

    // errors.As 用于保留结构化字段，而不是重新解析错误文本。
    var pathErr *os.PathError
    if errors.As(err, &pathErr) {
        return fmt.Sprintf("操作 %q 访问 %q 失败：%v", pathErr.Op, pathErr.Path, pathErr.Err)
    }
    return fmt.Sprintf("文件操作失败：%v", err)
}

这段代码体现了两个层次：errors.Is 负责回答“属于哪一类”，errors.As 负责回答“发生在哪个操作和路径”。二者一起使用，比把错误直接格式化成一段文本更容易接入日志、重试和用户提示。

兼容旧代码时怎样使用 os.IsNotExist

如果项目仍然使用较早的写法，可以看到下面这样的判断：

if _, err := os.Stat(path); err != nil {
    // 旧代码可以继续使用 os.IsNotExist，但新代码优先 errors.Is。
    if os.IsNotExist(err) {
        return fmt.Errorf("配置文件缺失：%w", err)
    }
    // 权限判断同样有旧谓词；不要把所有非 NotExist 错误当成权限问题。
    if os.IsPermission(err) {
        return fmt.Errorf("无权读取配置文件：%w", err)
    }
    return fmt.Errorf("检查配置文件失败：%w", err)
}

os.IsNotExist 和 os.IsPermission 并不是通过字符串匹配实现的，但它们只面向 os 包已知的错误。新代码使用 errors.Is 配合 io/fs 的标准错误值，更适合处理被包装的错误，也更容易与实现 fs.FS 的文件系统配合。

常见误区和发布前检查

• 不要写 strings.Contains(err.Error(), "不存在")：展示文字可能因操作系统或包装方式变化。
• 不要只判断 os.IsNotExist：权限拒绝、路径格式错误和 I/O 故障都需要独立处理。
• 不要为了得到提示文本而丢掉原始错误：用 %w 包装，后续仍可用 errors.Is 追溯。

落地时可以把检查收敛成三项：先用 errors.Is 做稳定分类，再用 errors.As 提取 PathError，最后用 %w 保留错误链。这样文件不存在和权限拒绝会有清晰分支，其它异常也不会被静默吞掉。

相关问题

为什么不能直接比较 err == fs.ErrNotExist？

文件 API 常返回包装后的 *os.PathError，直接比较只会比较最外层值；应使用 errors.Is 沿错误链判断。

errors.Is 和 errors.As 应该怎样分工？

errors.Is 判断是否属于某个标准错误类别，errors.As 尝试取得特定错误类型中的结构化字段。

权限判断是否能覆盖所有系统？

它表达的是 Go 文件系统错误中的“权限被拒绝”语义，具体系统仍可能返回其它底层错误，因此默认分支必须保留。