os.IsPermission仅识别内核返回的EACCES/EPERM类系统级权限拒绝错误，如open /root/file: permission denied；对路径不存在、只读磁盘、文件占用等场景返回false，需配合os.IsNotExist等协同判断。
os.IsPermission 判断的是哪类错误
它只识别系统级权限拒绝，比如 open /root/file: permission denied 这种由内核返回的 EACCES 或 EPERM 错误。不是所有“没权限”的场景都走这条路——比如路径不存在、磁盘只读、文件被占用，os.IsPermission 都会返回 false。
常见误用是拿它去兜底所有 I/O 失败：
if err != nil && !os.IsPermission(err) {
// 以为这里就是“真出错了”，其实可能是路径根本不存在
}
- 必须配合
os.IsNotExist、os.IsExist等一起判断，不能单靠os.IsPermission - Windows 下部分权限错误（如 ACL 限制）可能不触发
EACCES，os.IsPermission返回false - Go 1.19+ 对某些 NFS 挂载点的权限检查行为有变化，错误类型可能从
syscall.EACCES变成syscall.EIO
写文件前要不要主动检查权限
不要用 os.Stat + os.FileMode 位运算去“预判”能否写入——结果不可靠，且引入竞态：检查时可写，真正 os.Create 时可能已被 chmod 或 umask 干扰。
正确做法是直接操作，出错再分类处理：
立即学习“go语言免费学习笔记（深入）”；
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 写文件就用
os.OpenFile(path, os.O_CREATE|os.O_WRONLY, 0644)，别先os.Stat - 读文件也一样，别先
os.Access（Go 标准库甚至没提供这个函数） - 如果需要区分“没权限”和“路径错”，优先用
os.IsPermission和os.IsNotExist组合判断
chmod 后仍 Permission Denied 的典型原因
调用 os.Chmod 成功不代表后续操作就能通过权限检查。常见断点在：
- 父目录无
x权限（Linux/macOS）：即使目标文件权限是0777，若上层目录是0600，open仍报permission denied - 挂载选项限制：比如
mount -o ro或noexec，此时os.Chmod本身就会失败，错误不是os.IsPermission能捕获的 - SELinux/AppArmor 强制策略：错误信息可能仍是
permission denied，但底层是策略拦截，os.IsPermission仍为true，需查系统日志
跨平台处理 Permission Denied 的注意事项
Windows 没有 Unix-style 的 rwx 位，它的“权限拒绝”来源更杂：
- 文件被其他进程独占打开（如 Excel 正在编辑 .xlsx），错误是
The process cannot access the file because it is being used by another process.，os.IsPermission返回false - NTFS 权限或加密文件系统（EFS）导致的拒绝，Go 通常映射为
syscall.ERROR_ACCESS_DENIED，这时os.IsPermission才为true - UAC 虚拟化开启时，普通用户往
C:\Program Files写文件会被重定向到虚拟存储目录，不会报错；关掉 UAC 后才真正触发权限错误
所以跨平台时，别只依赖 os.IsPermission 做逻辑分支，要结合错误字符串或 errors.Is + 具体 syscall 错误码做细粒度判断。
真正麻烦的从来不是怎么判断 Permission Denied，而是错误发生时，你手头有没有足够上下文去定位是路径、父目录、挂载属性、还是策略引擎在拦你。
