✅ 正确判断文件是否存在应使用 os.Stat + os.IsNotExist：os.Stat 获取元数据且不打开文件，os.IsNotExist(err) 类型安全地识别“不存在”，可穿透错误包装并跨平台兼容；os.Lstat 适用于检查符号链接自身存在性；高频场景需避免重复 Stat，改用 os.ReadDir 或缓存；存在不等于可读或为普通文件，需额外校验权限与类型。
用 os.Stat + os.IsNotExist 是唯一靠谱的组合
Go 没有 os.Exists，旧版有过但早已弃用；直接看 err != nil 就说“文件不存在”是错的——它可能是权限拒绝、NFS 超时、坏符号链接，甚至磁盘离线。os.Stat 返回元数据，不打开文件，轻量且语义明确；而 os.IsNotExist(err) 才是专为识别“不存在”设计的类型安全判断，它能穿透错误包装（比如 fmt.Errorf("read failed: %w", err)），跨平台兼容 Unix 的 ENOENT 和 Windows 的 ERROR_FILE_NOT_FOUND。
- ✅ 正确写法：
_, err := os.Stat("config.yaml")；然后if err != nil && os.IsNotExist(err)→ 确实不存在 - ❌ 错误写法：
if err != nil { fmt.Println("文件不存在") }—— 会把permission denied也当成不存在 - ❌ 更错写法：
err == os.ErrNotExist或strings.Contains(err.Error(), "no such")—— 地址比较必失败，字符串匹配跨系统即崩
os.Stat 和 os.Lstat 到底该选哪个？
默认用 os.Stat：它会跟随符号链接，检查的是“最终目标是否存在”。比如 /etc/ssl/certs -> /etc/ssl/certs.d，os.Stat("/etc/ssl/certs") 实际检查的是 /etc/ssl/certs.d 是否存在。如果你要确认“这个软链文件本身在磁盘上”，比如部署脚本里检查配置软链是否被意外删除，就得换 os.Lstat——它只读链接自身 inode，哪怕目标路径已删、链接变悬空，只要链接文件还在，os.Lstat 就成功。
- 检查配置是否可读 → 用
os.Stat（你关心的是内容） - 检查部署包里某个软链是否打包正确 → 用
os.Lstat（你关心的是链接文件本身） - 两者都返回
*os.FileInfo，但os.Lstat不解引用，所以fi.Mode()&os.ModeSymlink != 0可用来确认它真是个链接
只查“有没有”，别反复 os.Stat —— 性能和竞态问题很真实
在轮询、热重载或高并发场景下，对同一路径高频调用 os.Stat 不仅慢（尤其 NFS、容器挂载卷），还可能因两次调用之间文件被删/改权限导致逻辑错乱：第一次 os.Stat 说存在，第二次 os.Open 却失败。这不是理论风险，而是生产环境常见问题。
根据 package.json 中的 engines 字段自动检测 Node.js 版本需求，未安装 nvm 时自动安装并切换至对应版本。支持 Windows、macOS、Linux。适用于 Node.js 项目开发、版本切换和环境配置。
- 批量检查多个文件（如插件目录）→ 改用
os.ReadDir(dir)一次读取所有fs.DirEntry，再遍历比对名字，避免 N 次系统调用 - 需频繁判断 → 加内存缓存（带 TTL 或事件驱动刷新），别裸写 for-loop + Stat
- 后续真要读文件 → 复用
os.Stat返回的fi，比如验证大小或 modtime 后再os.Open，减少 syscall 次数
别忘了：存在 ≠ 可读，也 ≠ 是普通文件
os.Stat 成功只说明路径存在且当前进程能获取其元信息，不代表你能打开它、读它、或它是个常规文件。很多 bug 出在假设“存在就等于可读配置”上。
立即学习“go语言免费学习笔记（深入）”；
- 要确保是普通文件（非目录、设备、socket）→ 检查
fi.Mode().IsRegular() - 父目录不可写？
os.Stat(filepath.Dir(path))先验 parent，再创建子项，避免os.Create直接报错 - Windows 下 ACL 或重解析点可能导致
os.Stat失败但非os.IsNotExist，这时应按业务区分处理：启动失败就退出，热加载就回退默认值
真正健壮的判断从来不是单次 os.Stat，而是结合场景、权限预期和失败后策略——比如配置文件缺失时报具体路径，而临时缓存文件不存在就静默重建。
