不能仅凭 err != nil 就认为文件不存在，因为 os.stat 失败可能由权限不足、坏链接、nfs 断开、windows acl 拒绝或 onedrive 重解析点等引起，真正代表路径不存在的只有 errors.is(err, os.errnotexist)。
直接用 os.Stat + errors.Is(err, os.ErrNotExist) 判断，别写 err == os.ErrNotExist 或字符串匹配错误信息——前者不兼容包装错误，后者跨平台不可靠。
为什么不能用 err != nil 就认为文件不存在
os.Stat 失败不等于路径不存在。它可能因为权限不足（syscall.EACCES）、符号链接断裂、NFS 挂载断开、Windows ACL 拒绝，甚至 OneDrive 重解析点触发而返回非 os.ErrNotExist 错误。这时候你误判为“不存在”，逻辑就偏了。
- 真正代表「路径在文件系统中根本未注册」的，只有
errors.Is(err, os.ErrNotExist) - 其他错误要单独处理：比如打印完整错误
fmt.Printf("stat err: %+v\n", err)，看是否含access denied或reparse point - 若需 fallback 到默认配置，但实际是权限问题，静默走默认反而掩盖真实故障
os.Stat 和 os.Lstat 该选哪个
默认用 os.Stat；只在明确要检查符号链接本身（而非目标）时换 os.Lstat。
-
os.Stat("link")→ 查的是link指向的文件是否存在。适合配置加载、日志读取等“我要内容”的场景 -
os.Lstat("link")→ 查的是link这个文件节点是否存在。适合部署脚本确认软链没被rm误删 - 对普通文件/目录，两者行为一致；别为了“存在性”无脑换
Lstat，除非你真需要链接自身语义 - Windows 下
os.Lstat支持有限，CI 中建议加runtime.GOOS == "windows"分支兜底
高频调用或并发场景下怎么避免踩坑
别先 os.Stat 再 os.ReadFile——这是典型的 TOCTOU 竞态，且多一次 syscall 开销。
- 真正想读文件？直接
os.ReadFile(path)，失败时用errors.Is(err, os.ErrNotExist)分支处理 - 需要元信息（大小、修改时间）？复用
os.Stat返回的os.FileInfo，别再调一次 - 批量检查多个路径？用
filepath.WalkDir一次性读目录树，内存过滤比逐个Stat快一个数量级 - 缓存
os.Stat结果要谨慎：路径可能被外部进程修改，缓存会过期
路径含中文、空格或特殊符号时要注意什么
确保传给 os.Stat 的是原始字节路径，不是被 shell 或日志框架二次 URL 编码或转义过的字符串。
- 用户输入路径先用
filepath.Clean规范化，去掉冗余..和. - 避免从
log.Printf或 HTTP query 参数里直接拼接路径——它们可能被自动转义 - Windows 下路径长度超 260 字符时，
os.Stat可能返回os.ErrNotExist而非更具体的错误，需提前截断或启用长路径支持
最常被忽略的点是：即使 os.Stat 成功返回，后续 os.OpenFile(path, os.O_WRONLY, 0) 仍可能失败——父目录权限刚被改、挂载点被 umount、或文件系统只读，这些都无法靠一次 Stat 预判。存在性只是瞬时快照，不是承诺。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
