Go os.Link 创建硬链接失败时怎么判断文件系统限制

os.Link(oldname, newname) 创建的是硬链接：两个路径指向同一个文件对象，而不是复制一份内容。创建失败时，最值得先看的不是完整错误字符串，而是 *os.LinkError 里面的底层错误。Linux 上，EXDEV 通常表示源文件和目标目录不在同一个挂载文件系统，EPERM 可能对应文件系统不支持硬链接、源是目录或权限策略拒绝；EACCES 则优先检查目录搜索和写权限。

判断 Go 硬链接失败的关键是先解包 LinkError，再按 errno 区分“跨设备”“无权限”“目标冲突”和“路径不存在”；只有确认硬链接不适用后，才选择复制或符号链接。

os.Link 失败先看这三个前置条件

先把问题缩小到三个对象：源文件、目标路径和它们所属的文件系统。源路径必须能被当前进程访问，目标路径的父目录必须存在并允许创建目录项，目标文件本身不能预先存在。硬链接不是快捷方式，成功后删除任意一个名字，另一个名字仍然可以访问同一份数据。

容器环境尤其容易出现“路径看起来都在项目目录，实际却跨 mount”的情况。源文件可能来自一个卷，目标目录来自另一个卷；此时路径拼接没有问题，内核仍会因为设备边界拒绝创建。先检查源文件和目标父目录的设备信息，再决定是否继续走硬链接。

用错误类型判断是跨文件系统还是权限问题

Go 文档明确说明 os.Link 出错时返回 *os.LinkError。下面的判断代码面向 Linux/类 Unix 环境，重点是保留底层原因；生产代码可把这段分类器放进 Unix 专用文件，避免把 syscall 常量直接带到不支持它们的平台。

package main

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

// classifyLinkError 把硬链接失败归类，方便上层决定是否降级。
func classifyLinkError(err error) string {
	if err == nil {
		return "ok"
	}

	var linkErr *os.LinkError
	if !errors.As(err, &linkErr) {
		return "unknown"
	}

	// EXDEV 表示跨挂载文件系统；这类错误重试原路径没有意义。
	if errors.Is(linkErr.Err, syscall.EXDEV) {
		return "cross-filesystem"
	}
	// EPERM/EACCES 需要继续检查文件系统能力、权限和安全策略。
	if errors.Is(linkErr.Err, syscall.EPERM) || errors.Is(linkErr.Err, syscall.EACCES) {
		return "permission-or-unsupported"
	}
	if errors.Is(linkErr.Err, syscall.EEXIST) {
		return "target-exists"
	}
	if errors.Is(linkErr.Err, syscall.ENOENT) {
		return "path-missing"
	}
	return "other"
}

func main() {
	err := os.Link("data/source.db", "backup/source.db")
	fmt.Println(classifyLinkError(err)) // 记录分类，不吞掉原始错误
}

分类结果应和运维动作对应，而不是见到 operation not permitted 就一直重试：

这里的 syscall 比较是平台相关的。跨平台库不要只返回字符串，建议定义自己的错误分类，再由各个 GOOS 文件把系统错误映射进去；这样上层只关心“可降级”还是“应报警”，不会依赖 Linux 的错误名。

把文件系统限制做成可恢复的兜底

如果业务只是希望“出现第二个可读文件”，可以在确认 EXDEV 或硬链接不受支持后复制内容；但复制会产生独立副本，后续写入不会同步。如果业务需要第二个名字始终跟随原文件，才考虑符号链接，同时接受目标移动后可能失效的边界。

比较稳妥的策略是：先保证目标父目录存在，再尝试一次 os.Link；遇到 EXDEV 直接进入明确的复制策略，遇到 EACCES 或 EPERM 记录运行用户、源路径、目标路径和底层错误，交给权限或部署配置修复；遇到 EEXIST 则按幂等语义决定复用、比较还是报冲突。不要用删除目标再重试替代并发控制，这可能误删别的任务刚创建的文件。

常见问题

硬链接和符号链接可以互相替代吗？

不能简单替代。硬链接共享同一个文件对象且不能跨文件系统；符号链接保存的是路径引用，可以跨文件系统，但目标移动或删除后会失效。

为什么容器里两个目录都在同一项目下，仍然返回 EXDEV？

容器把卷、临时目录或 bind mount 组合后，路径前缀相似不代表挂载边界相同。应检查源文件和目标父目录的设备或挂载信息，而不是只比较字符串路径。

os.Link 失败后应该自动重试吗？

只有临时 I/O 故障才值得有限重试。EXDEV、EEXIST、ENOENT 和多数 EPERM 都是确定性条件，应该修正路径、权限或降级策略。