文件移动

Go 里“移动文件”首先应尝试 os.Rename。如果源文件和目标文件位于不同挂载点，重命名可能返回包装后的跨设备错误；这时不要继续重试同一个调用，而应改成“复制到目标文件系统，再删除源文件”的两阶段方案。

官方文档：https://pkg.go.dev/os#Rename

判断重点是 errors.Is(err, syscall.EXDEV)，而不是比较错误字符串。确认跨文件系统后，用临时目标写完、同步、原子改名，最后再删除源文件。

先把 Rename 的失败原因分出来

os.Rename 返回的错误类型是 *os.LinkError，底层原因可能是权限不足、源文件不存在、目标路径冲突，也可能是操作系统拒绝跨文件系统重命名。Go 的错误会被层层包装，因此应该用 errors.Is 追踪错误树。

package main

import (
    "errors"
    "fmt"
    "os"
    "syscall"
)

func classifyRename(oldPath, newPath string) error {
    // 先尝试同文件系统内的快速移动；成功时不会复制文件内容。
    if err := os.Rename(oldPath, newPath); err == nil {
        return nil
    } else if errors.Is(err, syscall.EXDEV) {
        // EXDEV 表示两个路径不能通过同一次重命名跨越设备边界。
        return fmt.Errorf("需要复制型移动: %w", err)
    } else {
        // 其它错误要保留原始包装，便于调用方区分权限和路径问题。
        return fmt.Errorf("重命名失败: %w", err)
    }
}

这里的判断只回答“是否需要换成复制型移动”，不把所有 Rename 失败都当成跨文件系统。比如目标目录没有写权限时，复制同样会失败，继续换方案只会掩盖真正原因。

同一文件系统和跨文件系统，解决思路不同

同一文件系统内的重命名通常只改变目录项，适合处理临时文件改名、同目录替换和快速整理。Go 文档也提醒，源路径与目标路径处于不同目录时存在操作系统限制，非 Unix 平台即使同目录也不应假设一定是原子操作。

跨文件系统时，目标端没有办法直接接管源文件的目录项，所以要建立目标文件、复制字节、完成落盘，再决定是否删除源文件。这个过程不是原子移动：复制中断时，源文件仍应保留，目标临时文件则应清理。

如果只是想确认路径是否在同一个文件系统，不要用字符串比较路径前缀。挂载点、符号链接和容器路径都会让这种判断失真。更稳妥的做法是直接尝试 os.Rename，只对明确的 EXDEV 做复制型降级。

跨文件系统移动的最小安全写法

下面的实现把目标文件先写成同目录临时文件。这样即使复制过程被中断，读者或下游程序也不会看到一个正在增长的正式目标文件。

package mover

import (
    "errors"
    "fmt"
    "io"
    "os"
    "path/filepath"
    "syscall"
)

func MoveFile(srcPath, dstPath string) error {
    // 同文件系统优先使用 Rename，保留它的快速路径和替换语义。
    if err := os.Rename(srcPath, dstPath); err == nil {
        return nil
    } else if !errors.Is(err, syscall.EXDEV) {
        return fmt.Errorf("rename %s -> %s: %w", srcPath, dstPath, err)
    }

    src, err := os.Open(srcPath)
    if err != nil {
        return fmt.Errorf("open source: %w", err)
    }
    defer src.Close() // 复制失败时源文件仍保留，便于重试或人工处理。

    tmp, err := os.CreateTemp(filepath.Dir(dstPath), ".move-*")
    if err != nil {
        return fmt.Errorf("create destination temp: %w", err)
    }
    tmpName := tmp.Name()
    committed := false
    defer func() {
        // 未提交的临时文件不能留在目标目录，避免下次扫描误收。
        _ = tmp.Close()
        if !committed {
            _ = os.Remove(tmpName)
        }
    }()

    if _, err := io.Copy(tmp, src); err != nil {
        return fmt.Errorf("copy file: %w", err)
    }
    if err := tmp.Sync(); err != nil {
        return fmt.Errorf("sync destination: %w", err)
    }
    if err := tmp.Close(); err != nil {
        return fmt.Errorf("close destination: %w", err)
    }
    if err := os.Rename(tmpName, dstPath); err != nil {
        return fmt.Errorf("commit destination: %w", err)
    }
    committed = true
    if err := os.Remove(srcPath); err != nil {
        return fmt.Errorf("remove source after commit: %w", err)
    }
    return nil
}

关键顺序是：目标临时文件与正式目标在同一目录，复制完成后同步并改名，最后才删除源文件。生产项目使用 filepath.Dir 处理不同平台路径；示例保留了跨系统移动真正需要关注的资源释放和失败清理。

几个容易误判的边界

• 不要先删除目标。目标替换策略应明确：是否允许覆盖、是否需要备份；在复制完成前删除旧目标会扩大失败损失。
• 不要把跨文件系统移动当成原子操作。复制期间源和目标可能同时存在，进程重启后需要根据临时文件和业务元数据恢复。
• 目录移动不是文件移动的简单放大。io.Copy 只处理字节流；目录需要递归复制、权限和符号链接策略，最好单独设计。
• 源文件删除失败要单独报告。此时目标已经提交成功，重试整个移动可能造成覆盖或重复；更合适的是记录“已复制、待清理”。

可以按下面的速查表选方案：

相关问题

为什么不直接用 io.Copy 后删除源文件？

直接写正式目标会让其他进程读到半个文件。临时文件加同目录 Rename 能把“写入过程”和“可见目标”分开。

可以通过比较路径前缀判断是否跨盘吗？

不建议。挂载点和符号链接会让路径文字与实际文件系统边界不一致，直接处理 EXDEV 更可靠。

什么时候应该保留源文件？

只要移动过程承担数据迁移或跨系统传输，就应把源删除视为独立的最终动作，并为删除失败保留可恢复状态。