Go EvalSymlinks 为什么在目标不存在时失败

filepath.EvalSymlinks 在目标不存在时失败，是因为它不是纯字符串清理函数。它必须逐段访问真实文件系统，判断每个组件是不是符号链接，并在遇到链接时读取目标。普通路径组件不存在，或者符号链接最终指向不存在的目标，都会返回可由 errors.Is(err, fs.ErrNotExist) 识别的错误。

官方文档：https://pkg.go.dev/path/filepath#EvalSymlinks

背景：把“规范化路径”理解成一个动作会出错

路径处理至少包含两类不同工作。第一类是词法处理，只根据字符串消除多余分隔符、. 和可折叠的 ..；第二类是文件系统解析，需要查看磁盘上的目录项和符号链接。filepath.Clean 属于第一类，filepath.EvalSymlinks 属于第二类。

因此，EvalSymlinks("/data/new/report.txt") 不能凭空推断 new 或 report.txt 将来会对应什么对象。尤其当中间目录可能是符号链接时，不读取真实目录项就无法给出解析后的路径。

旧假设的问题：链接存在不代表目标存在

常见误区是先看到链接文件存在，就认为 EvalSymlinks 一定能返回结果。实际上，os.Lstat 可以读取链接本身的信息，不会跟随链接；而 EvalSymlinks 需要继续读取链接指向的目标。目标已经删除时，这就是断链，解析会失败。

标准库测试同时覆盖了两种不存在情况：直接传入不存在的名称，以及创建一个指向不存在目标的符号链接。两者都要求返回“不存在”错误。这不是平台偶然行为，而是标准库明确维护的边界。

真实规则：必须解析的组件都要可访问

当前实现遍历路径组件，对已拼出的路径调用 os.Lstat。如果组件是符号链接，再调用 os.Readlink 取得目标并继续解析。任意一次文件系统访问失败，错误都会直接返回；路径层级中还有剩余组件，但当前对象不是目录时，则会得到类似 ENOTDIR 的错误。

这也说明为什么 EvalSymlinks 适合回答“这个已经存在的路径最终指向哪里”，不适合回答“这个未来准备创建的路径应该长什么样”。后一个问题必须先明确哪些部分已经存在，哪些部分只是计划。

代码对比：现有路径要保留错误类型

当业务要求目标必须存在，例如读取配置文件或打开数据目录，应直接传播解析错误，同时用 errors.Is 判断错误类别。不要通过匹配错误字符串来区分缺失、权限和非目录问题。

package main

import (
	"errors"
	"fmt"
	"io/fs"
	"path/filepath"
)

func resolveExisting(path string) (string, error) {
	resolved, err := filepath.EvalSymlinks(path)
	if err == nil {
		return resolved, nil
	}

	if errors.Is(err, fs.ErrNotExist) {
		// 保留“不存在”这一可判断语义，交给调用方决定提示还是跳过。
		return "", fmt.Errorf("路径或链接目标不存在: %w", err)
	}

	// 权限、非目录、链接层级过多等错误不应伪装成缺失。
	return "", fmt.Errorf("解析符号链接失败: %w", err)
}

包装错误时使用 %w，上层仍可以继续执行 errors.Is(err, fs.ErrNotExist)。如果只返回格式化字符串，就会丢失机器可判断的原因。

新写法：待创建文件只解析已存在父目录

写入新文件时，文件本身本来就不存在。若直接对完整目标调用 EvalSymlinks，失败是预期行为。更合适的边界是：要求父目录已经存在，解析父目录中的符号链接，再把最终文件名拼接回去。

package main

import (
	"fmt"
	"path/filepath"
)

func resolveParentForCreate(path string) (string, error) {
	cleaned := filepath.Clean(path)
	parent, leaf := filepath.Split(cleaned)
	if leaf == "" || leaf == "." {
		return "", fmt.Errorf("目标必须包含文件名")
	}

	resolvedParent, err := filepath.EvalSymlinks(parent)
	if err != nil {
		// 这里只接受已存在父目录；父目录缺失时应先创建或明确报错。
		return "", fmt.Errorf("解析父目录失败: %w", err)
	}

	// leaf 尚不存在，只做词法拼接，不能声称它已经被解析过。
	return filepath.Join(resolvedParent, leaf), nil
}

这段代码只适用于“最终叶子不存在、直接父目录存在”的场景。如果连多级父目录都不存在，应先确定创建策略，而不是不断向上猜测并把所有缺失部分都当作普通字符串。因为这些目录在创建前后可能出现新的符号链接，语义会发生变化。

兼容注意：四个 API 不能互相替代

在 Windows 上，EvalSymlinks 还会进行平台相关的路径规范化；在 Unix 上则主要由逐段链接遍历完成。跨平台代码不应断言错误文本完全相同，应断言 errors.Is 结果和业务需要的路径性质。

采用建议：安全校验不要停在“解析后再打开”

如果路径来自不可信输入，仅仅先调用 EvalSymlinks、检查结果位于某个根目录，再调用 os.Open，仍可能存在检查与使用之间的竞态：攻击者可在两次操作之间替换链接。官方将这种模式归为 TOCTOU 风险。

Go 1.24 起提供 os.Root 一类受限根目录 API，可在根目录边界内执行打开等操作，减少路径遍历和链接竞态风险。它解决的是安全访问，不是让 EvalSymlinks 接受缺失目标；普通业务路径解析与不可信路径访问应分别设计。

最小判断清单

• 只是整理字符串：用 filepath.Clean。
• 要看链接文件本身：用 os.Lstat。
• 目标必须存在且要拿最终路径：用 filepath.EvalSymlinks。
• 准备创建最终文件：解析已存在父目录，再拼接叶子名。
• 处理不可信路径并立即打开：评估 os.Root，不要依赖解析后再检查的两步模式。

常见问题

EvalSymlinks 会自动创建缺失目录吗？

不会。它只解析已经存在的文件系统对象，不承担创建目录或文件的职责。

为什么 filepath.Clean 对不存在路径不会报错？

Clean 只处理路径字符串，不查询磁盘，所以路径是否存在与它无关。

链接本身存在，怎样判断它是不是断链？

先用 os.Lstat 可以确认链接本身存在；随后 os.Stat 或 EvalSymlinks 返回 fs.ErrNotExist，说明跟随后的目标不可达。

可以忽略 EvalSymlinks 的错误继续使用原路径吗？

不建议默认这样做。解析失败意味着你不知道失败发生在哪个组件；只有业务明确允许未解析路径，并对后续操作的错误和安全边界有处理时，才能选择保留原路径。