os.Open返回*os.PathError时，可通过类型断言提取Op、Path和Err字段；判断文件存在应优先用os.Stat而非os.Open；os.Create默认覆盖，无需先os.Remove；defer f.Close()后仍需检查Close错误。
os.Open 返回 *os.PathError 时怎么提取真实路径和操作名
Go 文件操作失败几乎都返回 *os.PathError，它不是简单字符串错误，而是结构体，含 Op（如 "open"）、Path（如 "./config.json"）、Err（底层 syscall 错误）。直接用 err.Error() 虽能打印，但不利于结构化处理。
- 用类型断言提取：
if pathErr, ok := err.(*os.PathError); ok { log.Printf("操作 %s 失败于路径 %s，底层错误: %v", pathErr.Op, pathErr.Path, pathErr.Err) } -
pathErr.Err可能是syscall.Errno（如syscall.ENOENT），可进一步 switch 判断具体系统错误码 - 注意：不是所有文件错误都是
*os.PathError，比如ioutil.ReadAll（已弃用）或io.ReadFull可能返回其他错误类型，需分别处理
检查文件是否存在该用 os.Stat 还是 os.IsNotExist
常见误区是用 os.Open + os.IsNotExist(err) 判断存在性——这会触发一次实际打开尝试，开销大且可能被权限拦截。正确做法是只查元信息。
- 优先用
os.Stat(path)，它只读取 inode，不打开文件，失败时再用os.IsNotExist(err)判断 -
os.IsNotExist(err)是安全的包装函数，内部判断err是否为*os.PathError且Err == syscall.ENOENT（Linux/macOS）或ERROR_FILE_NOT_FOUND（Windows） - 不要用
err == os.ErrNotExist比较，因为os.ErrNotExist是一个变量，而实际错误是它的副本，地址不同
os.Create 覆盖写入前要不要先 os.Remove
不需要。调用 os.Create(path) 本身就会截断（truncate）已有文件，等价于 os.OpenFile(path, os.O_RDWR|os.O_CREATE|os.O_TRUNC, 0644)。手动 os.Remove 再 os.Create 只会增加竞态风险和 syscall 开销。
- 若需确保“新建”语义（即拒绝覆盖已有文件），改用
os.OpenFile(path, os.O_WRONLY|os.O_CREATE|os.O_EXCL, 0644)，此时若文件已存在会返回*os.PathError且Err == syscall.EEXIST -
os.Create在 Windows 下对正在被其他进程读取的文件可能失败（ERROR_SHARING_VIOLATION），这不是 Go 层问题，需业务层重试或提示用户关闭文件
defer f.Close() 后还要检查 Close 错误吗
要。尤其在写入场景下，f.Close() 才真正触发缓冲区刷盘和磁盘 I/O，很多“磁盘满”“只读文件系统”错误直到这时才暴露。
立即学习“go语言免费学习笔记（深入）”；
- 不能只写
defer f.Close()就认为万事大吉；必须捕获并处理Close()的返回错误 - 推荐模式：
f, err := os.Create("log.txt") if err != nil { return err } defer func() { if cerr := f.Close(); cerr != nil && err == nil { err = cerr // 仅当主逻辑无错时，用 Close 错误覆盖 } }() - 若主逻辑已出错（如写入中途 panic），
Close错误只是次要信息，不应掩盖原始错误
文件操作错误的真实复杂性不在 API 调用本身，而在跨平台 errno 映射、defer 生命周期与 I/O 延迟错误的交织。别依赖 err.Error() 字符串匹配，始终做类型断言和 errno 分支处理。Windows 下的共享锁、Linux 下的 noatime 挂载、NFS 等网络文件系统的行为差异，都会让同一段代码在不同环境表现出不同错误路径。
