Golang文件操作错误分类处理方法

os.IsTemporary 专用于检测系统调用返回的可重试错误码（如EAGAIN、EWOULDBLOCK），非通用“是否该重试”判断；实际应结合syscall错误码、操作类型及文件系统语义综合判定。

Go 文件操作中 os.IsTemporary 的真实用途

它不是用来判断“这个错误是不是临时的”，而是专门检测底层系统调用是否返回了明确标记为可重试的错误码（比如 EAGAIN、EWOULDBLOCK、ETIMEDOUT 等）。很多常见文件错误，例如 os.IsNotExist(err) 或 os.IsPermission(err)，哪怕看起来“好像能重试”，os.IsTemporary 也返回 false —— 因为它们在 POSIX 层面不属于临时性系统错误。

实际使用时要注意：

• os.IsTemporary 对 os.Open 失败几乎总是 false（除非极特殊内核配置或 NFS 挂载异常）
• 它更常用于 net.Conn、syscall.Read 或自定义 io.Reader 实现中
• 不要把它当作通用“是否该重试”的开关

区分致命错误的实用判断链：从 os.PathError 开始

Go 文件操作失败大多返回 *os.PathError，它的 Err 字段才是关键。真正决定是否致命，得看这个底层错误值本身：

if err != nil {
    if pathErr, ok := err.(*os.PathError); ok {
        switch pathErr.Err {
        case syscall.ENOENT:
            // 路径不存在 → 通常致命（除非你本就预期它可能不存在）
        case syscall.EACCES, syscall.EPERM:
            // 权限不足 → 几乎总是致命（改权限或换用户才能解决）
        case syscall.EBUSY:
            // 设备忙（如正在 umount 的挂载点）→ 临时？不一定，需结合场景
        default:
            // 其他 syscall 错误 → 查 man 2 open 判断语义
        }
    }
}

比单纯调 os.IsNotExist 更进一步：它让你看到原始 syscall 错误码，避免被封装层掩盖细节。

重试逻辑不该只靠错误类型，还得看操作语义

同一个错误，在不同操作下处理方式完全不同：

• os.Create 遇到 ENOSPC（磁盘满）→ 致命，重试无意义
• os.OpenFile(..., os.O_WRONLY|os.O_APPEND, 0) 遇到 EINTR → 可安全重试（系统调用被信号中断）
• os.Rename 在某些文件系统上返回 EXDEV → 致命（跨设备移动不支持），必须降级为 copy+remove
• 对 NFS 挂载点调 os.Stat 返回 ESTALE → 临时？其实是挂载已失效，应重新挂载而非重试

也就是说，没有放之四海而皆准的“临时/致命”二分法；必须结合：syscall 错误码 + 具体操作（open/create/rename/stat） + 目标路径类型（本地磁盘/NFS/procfs）。

生产环境建议：用错误包装 + 自定义判定函数

直接在每个 if err != nil 里写大段 switch 不可持续。推荐封装一层：

type FileOpError struct {
    Op   string
    Path string
    Err  error
}

func (e *FileOpError) IsRetryable() bool {
    if e.Err == nil {
        return false
    }
    if os.IsTimeout(e.Err) || os.IsTemporary(e.Err) {
        return true
    }
    if pathErr, ok := e.Err.(*os.PathError); ok {
        switch pathErr.Err {
        case syscall.EINTR, syscall.EAGAIN, syscall.EWOULDBLOCK:
            return true
        case syscall.ENOSPC, syscall.ENOTDIR, syscall.EISDIR:
            return false // 明确不可重试
        }
    }
    return false
}

这样后续逻辑就干净了：if fileErr.IsRetryable() { time.Sleep(); continue }。但注意：IsRetryable 仍不能替代业务判断 —— 比如写日志时遇到 ENOSPC，你可能要触发告警并切换到备用存储，而不是简单重试。

最常被忽略的一点：os.File 的 Write 和 Read 方法可能返回 n > 0, err == nil 或 n > 0, err == io.EOF，此时错误不是“致命”与否的问题，而是你是否正确处理了部分成功 —— 这比分类错误本身更容易出 bug。