os.Stat 返回 os.ErrNotExist 表示文件不存在，须用 errors.Is(err, os.ErrNotExist) 精准判断；成功时可获取 FileInfo 信息；优先直接操作（如 os.ReadFile）而非先 Stat；注意 Windows 误报、竞态问题及错误处理兜底。
os.Stat 返回 os.ErrNotExist 就代表文件不存在
Go 没有单独的 FileExists 函数，靠 os.Stat 的错误类型判断。调用后如果 err 不为 nil，再用 errors.Is(err, os.ErrNotExist) 做精准比对——不能直接写 err == os.ErrNotExist，因为底层可能返回的是包装错误（比如 &os.PathError{Err: os.ErrNotExist}）。
常见错误现象：os.Stat("xxx").Err == os.ErrNotExist 总是 false；或者用 strings.Contains(err.Error(), "no such file") 这种字符串匹配，极不可靠（不同系统报错文本不同）。
- 必须用
errors.Is(err, os.ErrNotExist)判断，Go 1.13+ 标准做法 -
os.Stat成功时返回的os.FileInfo可顺便拿到大小、modtime 等信息，别浪费 - 如果只关心“是否存在”，且路径可能是符号链接，注意
os.Stat会跟随链接；要检查链接本身存在用os.Lstat
用 os.ReadFile 或 os.Open 代替 os.Stat 更高效
很多场景其实不是“先判断再操作”，而是“想读/写这个文件，但怕它不存在导致 panic”。这时候硬加一层 os.Stat 是多余的 IO 开销，直接尝试操作 + 捕获错误更干净。
使用场景：配置加载、日志写入、模板读取等典型“存在就用，不存在就走默认逻辑”的情况。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 读文件优先用
os.ReadFile(path)，失败时检查errors.Is(err, os.ErrNotExist) - 需要流式读或控制句柄生命周期，用
f, err := os.Open(path)，记得defer f.Close() - 避免
os.Stat+os.Open两次系统调用，尤其在高频路径（如 HTTP handler）里影响明显
Windows 下注意长路径和权限错误容易被误判为 os.ErrNotExist
Windows 对路径长度（>260 字符）、ACL 权限、重解析点（如 OneDrive 同步文件）比较敏感。os.Stat 在这些情况下也可能返回 os.ErrNotExist，而非更具体的 os.ErrPermission 或其他错误。
性能 / 兼容性影响：这会导致你本想 fallback 到默认配置，结果却因权限问题静默用了错误路径。
- 遇到疑似误判，先打印完整错误：
fmt.Printf("stat err: %+v\n", err)，看是否含access denied或reparse point - 必要时补充权限检查：用
os.Access(path, os.R_OK)（需 Go 1.22+），或手动解析os.PathError的Err字段 - 路径含中文、空格、特殊符号时，确保传入的是原始字节路径，不要被 shell 或日志框架二次转义
并发场景下 os.Stat 判断后立即操作仍可能失败
“检查-然后-执行”（check-then-act）天生有竞态：A 协程判断文件存在，B 协程立刻删掉它，A 再去 os.Open 就 panic。这不是 Go 的问题，是所有语言共有的 TOCTOU（Time-of-check to time-of-use）问题。
容易踩的坑：把 os.Stat 当作原子保护手段，尤其在临时文件清理、锁文件检测等逻辑里。
- 关键操作必须容忍
os.ErrNotExist，即：判断只是提示，执行时仍要处理错误 - 需要强一致性时，改用原子操作：比如用
os.WriteFile(path, data, 0644)覆盖写，或用os.CreateTemp+os.Rename替代“先判断再创建” - 分布式环境？别依赖本地文件存在性判断，改用协调服务（etcd/ZooKeeper）或数据库状态
真正麻烦的从来不是“怎么判断”，而是“判断之后你以为安全了，其实没安全”。文件系统行为在不同 OS、挂载选项、容器环境里差异很大，留一手错误处理比追求一次判断准确重要得多。
