PathError断言失败主因是错误链中无该类型，仅路径相关系统错误（如ENOENT）才生成；应优先用errors.As提取*os.SyscallError并比对syscall码，而非依赖PathError或os.IsPermission等。
Go 中 PathError 类型断言失败的常见原因
直接用 errors.As 或类型断言获取 *os.PathError 失败，往往不是代码写错了，而是错误链里根本没包这个类型——比如你调用的是 os.OpenFile，但传了只读 flag 去写文件，底层触发的是 syscall.EBADF，最终错误是 *os.SyscallError，不是 *os.PathError。
关键点：只有系统调用明确返回了路径相关错误（如 ENOENT、EACCES、EBUSY），且 Go 标准库封装时才生成 *os.PathError；其他情况可能落在 *os.SyscallError、*exec.Error 甚至自定义错误里。
-
PathError的Op字段必须匹配操作名（如"open"、"remove"），Path字段非空，Err是 syscall 错误码 - Windows 下文件被占用通常报
ERROR_SHARING_VIOLATION，Go 会转成syscall.ERROR_SHARING_VIOLATION，但不会自动包装成*os.PathError，而是*os.SyscallError - 用
errors.As(err, &pe)前，先确认 err 不是 nil，且最好配合errors.Is判断底层是否是预期错误码（如syscall.EBUSY）
判断“文件被占用”的可靠方式（跨平台）
别只盯着 PathError，Windows 和 Linux 对“占用”的语义不同：Linux 一般不阻塞删除正在写的文件（inode 还在），而 Windows 会直接拒绝任何打开/删除/重命名操作。所以真正要捕获的是底层 syscall 错误码。
- Windows 常见占用错误码：
syscall.ERROR_SHARING_VIOLATION、syscall.ERROR_ACCESS_DENIED（尤其当另一进程以独占模式打开） - Linux 常见对应行为：
syscall.EBUSY（如卸载设备时）、syscall.EAGAIN（某些锁场景），但普通文件被读写一般不报错 - 推荐做法：用
errors.As(err, &se)尝试提取*os.SyscallError，再检查se.Err是否等于目标 syscall 错误码，而不是强依赖PathError
示例：
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
var se *os.SyscallError
if errors.As(err, &se) && (se.Err == syscall.ERROR_SHARING_VIOLATION || se.Err == syscall.EBUSY) {
// 文件很可能被占用
}
os.IsPermission 和 os.IsNotExist 为什么不能用来判断占用
这两个函数只是快捷包装，内部调用 errors.Is(err, syscall.EACCES) 或 errors.Is(err, syscall.ENOENT)，和“文件被占用”完全无关。EACCES 是权限不足，ENOENT 是路径不存在——它们可能和占用同时出现（比如你试图删一个被 Excel 锁住的文件，Windows 可能返回 ERROR_ACCESS_DENIED 而非 ERROR_SHARING_VIOLATION），但语义上不能等价替换。
-
os.IsPermission检查的是syscall.EACCES或syscall.EPERM，不是ERROR_SHARING_VIOLATION - 即使错误信息里含 “access denied”，也不能直接用
os.IsPermission替代对具体 syscall 错误码的判断 - 真正需要的是：明确知道你在处理哪个系统、哪个 API、哪个错误码，然后针对性匹配
实际处理被占用文件的建议流程
不要指望一次类型断言搞定所有平台所有场景。真实项目里更稳妥的做法是分层检测 + 降级策略。
- 先尝试操作（如
os.Remove），不预检——因为预检（os.Stat）和操作之间存在竞态 - 错误发生后，优先用
errors.As提取*os.SyscallError，再比对平台相关错误码 - Windows 下可额外考虑调用
syscall.GetLastError()（需unsafe和golang.org/x/sys/windows），但多数情况标准库已封装足够 - 如果只是想“等几秒再试”，别用
time.Sleep硬等，改用带超时的重试循环，并记录错误码变化（避免无限重试EACCES这类永久错误）
最常被忽略的一点：很多所谓“被占用”，其实是当前进程自己没关掉 *os.File，或者 defer Close() 写在了错误分支之外——先查自己的资源泄漏，比查错误类型更快。
