Go os.Stat 判断文件存在时为什么不能忽略所有错误

用 Go 的 os.Stat 判断路径时，真正安全的判断不是“err != nil 就说明文件不存在”，而是把结果拆成三类：err == nil 表示可以读取到文件信息；errors.Is(err, fs.ErrNotExist) 表示目标确实不存在；其他错误则必须保留并处理。权限不足、路径前缀不可访问、文件系统异常都可能落在第三类，直接忽略会让程序误创建、误覆盖或掩盖故障。

先把 os.Stat 的三个结果分开

os.Stat 成功时返回 FileInfo；失败时返回一个错误。判断逻辑可以先画成下面这张静态关系图：错误对象可能带着路径和系统调用信息，但业务真正关心的是它是否匹配某个文件系统哨兵错误。

用 errors.Is 判断“确实不存在”

文件操作常返回带上下文的 *fs.PathError，错误文本里通常还会包含操作名和路径。字符串比较既脆弱，也无法正确处理包装错误。Go 的错误文档明确建议用 errors.Is 遍历错误链；文件系统场景对应的哨兵值是 fs.ErrNotExist。

package main

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

func missing(path string) (bool, error) {
	_, err := os.Stat(path)
	if err == nil {
		return false, nil // 能读到元数据，路径存在
	}
	if errors.Is(err, fs.ErrNotExist) {
		return true, nil // 只把明确的缺失交给创建分支
	}
	return false, err // 权限等异常必须继续向上报告
}

这里返回两个值，是为了让调用方区分“缺失”与“检查失败”。如果只返回一个布尔值，权限错误很容易被压成 false 或 true，最后变成错误的业务决策。

权限错误不能当成可创建路径

例如进程没有权限穿过某一级目录时，Stat 可能返回权限相关错误。此时文件也许存在，只是当前进程不能观察它。若代码把所有错误都写成“没有文件”，随后执行 os.MkdirAll、写入或覆盖，就会把访问问题变成更难追的二次故障。

生产代码可以在保留通用错误返回的同时，对权限做更具体的日志或提示：

func ensureConfig(path string) error {
	_, err := os.Stat(path)
	if err == nil {
		return nil // 已存在时不要重复创建
	}
	if !errors.Is(err, fs.ErrNotExist) {
		return fmt.Errorf("检查配置文件 %q: %w", path, err) // 保留原始原因
	}
	// 只有确认不存在，才执行创建或初始化动作。
	return os.WriteFile(path, []byte("{}\n"), 0o600)
}

上面的片段如果单独编译，还需要补充 fmt 导入。重点不在于创建文件，而在于创建动作必须由 fs.ErrNotExist 分支明确触发。

把错误边界留在调用链里

如果上层还需要判断权限，可以使用 errors.Is(err, fs.ErrPermission)；但不要为了“判断存在”而吞掉所有错误。对外返回时用 %w 包装路径和操作，上层仍能继续用 errors.Is 判断原因。

常见问题

os.IsNotExist 还能不能用？

可以用于兼容旧代码，但官方文档说明它只支持 os 包返回的错误；新代码更适合使用 errors.Is(err, fs.ErrNotExist)。

Stat 成功就一定是普通文件吗？

不一定。它也可能指向目录、符号链接解析后的目标或其他文件系统对象，需要再通过 FileInfo.IsDir 等信息判断类型。

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

因为错误可能被 *fs.PathError 或业务层用 %w 包装，直接相等比较会漏掉这些合法情况。

记住一个边界即可：os.Stat 的非 nil 错误只是“检查没有成功”，只有 errors.Is(err, fs.ErrNotExist) 才能支持“目标不存在”的业务结论。