os.Stat报错不表示路径一定不存在，可能因权限、坏链接或I/O错误；应使用os.IsNotExist判断；检查符号链接自身需用os.Lstat而非os.Stat。
os.Stat 返回 error 时不一定代表路径不存在
很多人看到 os.Stat 报错就直接认为“文件或目录不存在”，其实不是。它可能因为权限不足、路径是坏符号链接、磁盘 I/O 错误等失败，而路径本身完全合法。
正确做法是用 os.IsNotExist 显式判断错误类型：
fi, err := os.Stat("/path/to/thing")
if err != nil {
if os.IsNotExist(err) {
// 真正不存在
} else {
// 其他错误：比如 permission denied、too many symlinks...
}
return
}
// fi != nil，说明路径存在且可访问
-
os.IsNotExist是唯一可靠的“不存在”断言方式，别用err != nil简单代替 - 注意：
os.IsNotExist对目录和文件一视同仁，不区分类型 - 如果路径是 dangling symlink（悬空软链），
os.Stat默认会跟随并报os.IsNotExist；想检查软链自身是否存在，得用os.Lstat
os.Lstat 和 os.Stat 的关键区别在哪
当路径可能是符号链接时，选错函数会导致逻辑翻车。比如你想确认一个软链文件是否被创建，但用了 os.Stat，它会去查目标路径——目标可能还没建，你就误判软链不存在。
这时候必须用 os.Lstat：
立即学习“go语言免费学习笔记（深入）”；
fi, err := os.Lstat("/path/to/symlink")
if err == nil && fi.Mode()&os.ModeSymlink != 0 {
// 这是个有效的软链（哪怕指向无效路径）
}
-
os.Stat：解析符号链接，返回目标的文件信息 -
os.Lstat：不解析符号链接，返回链接自身的元数据 - 检查软链存在性、权限、修改时间等“链接本身属性”时，必须用
Lstat - Windows 下软链支持有限，
Lstat行为可能与 Unix 不一致，CI 中建议加平台判断
os.Stat 性能开销比你想象中大
每次调用 os.Stat 都是一次系统调用，涉及内核态切换，在循环里频繁检查路径存在性（比如轮询）会明显拖慢程序。
- 如果只是“存在即用”，建议直接
os.Open或os.ReadFile，靠它们的 error 处理，避免多一次 stat - 高频场景（如热重载配置目录扫描）可用
filepath.WalkDir一次性读取目录树，再内存过滤，比逐个Stat快一个数量级 - 注意：
os.Stat不缓存结果，两次调用相同路径也会触发两次系统调用
跨平台路径存在性检查的隐藏坑
Windows 对大小写不敏感，但 os.Stat 在某些版本 Go 中仍可能因大小写差异返回 os.IsNotExist；另外，UNC 路径、驱动器根路径（如 C:）、长路径（>260 字符）在 Windows 上行为不稳定。
- 对用户输入的路径，先用
filepath.Clean规范化，再检查 - Windows 下若需严格匹配，可配合
filepath.VolumeName提前提取盘符，再用os.ReadDir列出父目录内容做字符串比对（不推荐，仅作兜底） - 不要假设
os.Stat("C:")一定成功——它在某些权限受限环境会失败，而os.Stat("C:\")才更可靠
os.Stat，而是想清楚你到底要问系统什么：是“这个路径指向的东西在不在”，还是“这个路径字符串本身能不能被解析成一个合法入口”。后者往往需要组合 Lstat、Mode 标志位、甚至手动解析 symlink 目标。 
