本文介绍如何在 Go 中通过解析 os.Rename 返回的 *os.LinkError 及其底层 syscall.Errno，跨语言环境、稳定可靠地检测“目录被占用”等系统级重命名失败原因，尤其适用于 Windows 平台的错误码（如 ERROR_SHARING_VIOLATION = 32）。
本文介绍如何在 go 中通过解析 `os.rename` 返回的 `*os.linkerror` 及其底层 `syscall.errno`，跨语言环境、稳定可靠地检测“目录被占用”等系统级重命名失败原因，尤其适用于 windows 平台的错误码（如 error_sharing_violation = 32）。
在 Go 中调用 os.Rename 时，若目标路径被其他进程占用（例如资源管理器正打开该文件夹、IDE 锁定其中文件，或防病毒软件正在扫描），操作会失败。此时仅依赖 err.Error() 字符串匹配（如检查是否包含德文 "Der Prozess kann nicht auf die Datei zugreifen..."）是不可靠的——它随系统语言变化，且易受格式微调影响。
正确做法是类型断言并提取底层系统错误码。os.Rename 在失败时返回的是 *os.LinkError 类型错误，其 Err 字段封装了原始操作系统错误（syscall.Errno）。我们可据此进行平台安全的数值比对：
import (
"fmt"
"os"
"runtime"
"syscall"
)
func renameSafely(oldPath, newPath string) error {
err := os.Rename(oldPath, newPath)
if err == nil {
return nil
}
// 断言为 *os.LinkError
linkErr, ok := err.(*os.LinkError)
if !ok {
return fmt.Errorf("unexpected error type: %w", err)
}
// 断言底层 Err 为 syscall.Errno
sysErr, ok := linkErr.Err.(syscall.Errno)
if !ok {
return fmt.Errorf("failed to extract syscall error: %w", err)
}
// Windows 特定错误码：32 = ERROR_SHARING_VIOLATION（文件被其他进程占用）
if runtime.GOOS == "windows" && sysErr == 32 {
return fmt.Errorf("rename failed: directory '%s' is in use by another process (error 32)", linkErr.Old)
}
// 更规范的写法（推荐）：使用 syscall 包预定义常量（需注意版本兼容性）
// 例如 Windows 下可导入 golang.org/x/sys/windows 并使用 windows.ERROR_SHARING_VIOLATION
// 但若仅需基础支持，直接比对数值 32 是简洁有效的方案
return fmt.Errorf("rename failed: %w", err)
}
⚠️ 注意事项：
- syscall.Errno 的值是平台相关的：Windows 的 32 对应 ERROR_SHARING_VIOLATION，Linux/macOS 则无直接等价码（通常表现为 EBUSY，即 syscall.EBUSY = 16），因此务必结合 runtime.GOOS 做条件判断；
- Go 标准库 syscall 包中部分常量（如 syscall.EBUSY）已标记为 deprecated，生产环境建议迁移到 golang.org/x/sys/unix（Linux/macOS）或 golang.org/x/sys/windows（Windows）以获取更稳定、语义清晰的错误常量；
- 永远优先使用类型断言而非字符串匹配——它不依赖本地化消息，具备编译期可验证性与运行时稳定性；
- 调试时善用 fmt.Printf("%#v\n", err) 查看错误结构全貌，快速定位 LinkError.Err 的真实数值。
总结：通过两层类型断言（*os.LinkError → syscall.Errno），即可获得与系统语言无关、可编程判断的错误标识。对于 Windows 场景下“目录被占用”这一高频问题，直接比对 sysErr == 32 是简洁、高效且可靠的解决方案。
