应使用 os.isnotexist(err) 判断文件不存在，os.ispermission(err) 判断权限不足；二者互斥但不穷尽所有错误，需分别处理并注意路径访问链、符号链接、跨平台差异及真实环境限制。
怎么用 os.IsPermission 和 os.IsNotExist 区分错误类型
Go 的文件 IO 操作（比如 os.Open、os.Stat）出错时统一返回 error 接口，不能直接用 == 判断字符串。必须用标准库提供的判定函数——它们内部检查底层 errno 或具体错误实现，比字符串匹配可靠得多。
常见错误现象：写了个配置加载逻辑，os.Open("config.yaml") 失败后只打印 err.Error()，结果线上日志里全是 "permission denied" 和 "no such file" 混在一起，根本没法自动分流处理。
-
os.IsPermission(err)返回true当且仅当错误源于权限不足（如无读/执行权限、目录不可遍历） -
os.IsNotExist(err)返回true当且仅当路径对应实体不存在（注意：对 symlink 指向的不存在目标也返回true） - 两者互斥但不穷尽——比如磁盘满、网络文件系统超时、设备忙等会返回
false，需单独处理
fi, err := os.Stat("secret.txt")
if err != nil {
if os.IsNotExist(err) {
log.Println("配置文件未部署")
} else if os.IsPermission(err) {
log.Println("检查文件权限和父目录可执行位")
} else {
log.Printf("其他IO错误: %v", err)
}
return
}
os.OpenFile 的 flag 参数怎么影响权限错误触发时机
用 os.OpenFile 打开文件时，传入的 flag 会决定系统调用层级的行为。比如 os.O_RDONLY 只校验读权限；而 os.O_RDWR | os.O_CREATE 在文件不存在时会尝试创建，此时若父目录无写权限，错误仍是 permission denied，但原因其实是“无法在目录中创建文件”，不是“文件本身没权限”。
容易踩的坑：以为 os.IsPermission 只对应文件自身的 chmod，其实它覆盖整个路径访问链——包括所有中间目录的执行权限（即能否 chdir 进去）。Linux 下目录缺少 x 位就无法 open() 其下任何文件，哪怕目标文件权限是 777。
立即学习“go语言免费学习笔记（深入）”；
- 用
os.O_CREATE时，权限错误可能来自父目录，而非目标文件路径本身 -
os.O_TRUNC需要写权限，即使只是清空已有文件内容 - Windows 下权限模型不同，
os.IsPermission对只读文件的写操作也会返回true，但语义更接近“拒绝访问”
为什么 os.IsNotExist 对 symlink 失效？真实路径不存在时怎么判断
os.IsNotExist 在 os.Stat 或 os.Lstat 上行为不同：os.Stat 走 symlink 解引用，如果最终目标不存在，它返回 os.IsNotExist == true；但 os.Lstat 只查 symlink 自身，只要 symlink 文件存在，就不会触发 os.IsNotExist。
使用场景：你收到一个路径，不确定是普通文件还是 symlink，又想确认“这个路径最终指向的东西到底存不存在”。这时候不能只靠一次 os.Stat ——因为 symlink 自身存在但目标失效（dangling symlink），os.Stat 会返回 os.IsNotExist；但如果 symlink 不存在，os.Stat 同样返回 os.IsNotExist，你无法区分是“链接文件丢了”还是“链接指向的东西丢了”。
- 先用
os.Lstat检查路径自身是否存在（避免误判 dangling symlink） - 若存在且是 symlink，再用
os.Stat查目标；两次都失败才说明路径彻底无效 - 注意：某些容器环境或 NFS 卷可能让
os.Lstat成功但os.Stat因跨挂载点失败，此时错误既不是IsNotExist也不是IsPermission
跨平台时 os.IsPermission 的边界情况
Linux/macOS 下权限错误通常对应 EACCES 或 EPERM；Windows 下则混用 ERROR_ACCESS_DENIED、ERROR_SHARING_VIOLATION 等多种状态。Go 的 os.IsPermission 内部做了适配，但仍有几个实际差异：
性能影响：这些判定函数本身开销极小（只是类型断言或整数比较），但频繁调用说明你在做错误恢复逻辑，要注意别在热路径里反复 Open→失败→判错→重试。
- Windows 上以只读方式打开正在被其他进程独占写的文件，会返回
os.IsPermission == true，但本质是共享冲突，不是 Unix 风格的权限位问题 - macOS 的 sandboxed 应用（如 App Store 版本）可能对特定目录返回模糊错误，
os.IsPermission为true，但实际需要用户授权而非改 chmod - 容器中挂载的 host 路径若用
root创建，非 root 容器进程访问时，os.IsPermission为true，但ls -l看权限位可能是755——这是 UID/GID 映射导致的，不是 Go 的问题
最常被忽略的一点：错误判定之后的处理逻辑，往往假设了“权限问题=该改 chmod”或“不存在=该建文件”，但真实生产环境里，前者可能是 SELinux/AppArmor 限制，后者可能是挂载点未就绪。别让判定函数成了思维捷径。
