Go filepath.Rel 组合 Clean 与根目录校验

在 Go 里把用户传入的文件限制在某个根目录下，不能只写 strings.HasPrefix。例如根目录是 /srv/app，候选路径是 /srv/app2/log.txt，字符串前缀虽然相同，但它并不属于根目录。更稳妥的组合是：先用 filepath.Clean 做词法归一化，再用 filepath.Rel 观察目标相对根目录的结果，最后拒绝 .. 越界。

官方地址：https://pkg.go.dev/path/filepath

结论先说：Clean 解决路径写法不统一，Rel 解决“目标相对根目录在哪里”。当结果等于 ..，或以 .. 加系统分隔符开头时，就应把它判定为根目录之外；但这套判断仍是词法规则，不会自动穿透符号链接。

先把 Clean 和 Rel 的职责分开

我第一次处理这类路径时，容易把“路径长得像”误当成“路径属于目录”。实际上，Clean 只处理路径文本：压缩重复分隔符、去掉 .，并消解能够配对的 ..。它不会访问磁盘，也不会判断文件是否存在。

Rel(base, target) 则回答另一个问题：从 base 出发，怎样用相对路径表示 target。Go 官方文档还说明，Rel 会清理返回结果；所以不要把它当成“自动完成所有安全检查”的函数，而要把返回值当作判断边界的材料。

因此，下面这些输入应该先被统一理解：/srv/app/./logs 归一化为 /srv/app/logs，/srv/app/cache/../logs 归一化后也落在 /srv/app/logs；而 /srv/app/../secret 会变成根目录外的 /srv/secret。

根目录校验要检查什么

判断结果时要特别处理两个边界。第一，结果为 . 表示目标就是根目录本身；接口是否允许它，要由业务决定。第二，不能只判断结果中是否出现两个点，因为目录名可以合法地叫 ..data。真正可靠的词法判断是比较完整路径段：结果等于 ..，或者以 .. 和当前系统分隔符开头。

根目录和目标都先要求是绝对路径，能减少当前工作目录带来的歧义。若两个路径跨盘符或卷名，Rel 可能直接返回错误；这个错误应保留给调用方，而不是悄悄改成一个看似安全的字符串。

把组合逻辑收成一个函数

下面的函数允许目标等于根目录，返回 .；如果你的业务只接受根目录下的文件，可以再把 rel == "." 单独拒绝。代码只做词法检查，适合在路径路由、归档目录或导出目录选择之前建立清晰边界。

package main

import (
	"errors"
	"fmt"
	"path/filepath"
	"strings"
)

// relativeInside 只按路径文本判断 target 是否位于 root 内。
func relativeInside(root, target string) (string, error) {
	// 先统一 .、.. 和重复分隔符，避免同一位置出现多种写法。
	root = filepath.Clean(root)
	target = filepath.Clean(target)
	if !filepath.IsAbs(root) || !filepath.IsAbs(target) {
		return "", errors.New("root 和 target 都必须是绝对路径")
	}

	// Rel 负责把目标表达为相对 root 的结果，也会报告跨卷等错误。
	rel, err := filepath.Rel(root, target)
	if err != nil {
		return "", fmt.Errorf("计算相对路径失败: %w", err)
	}

	// 完整匹配路径段，避免把 ..data 误判成越界的 ..。
	parent := ".."
	if rel == parent || strings.HasPrefix(rel, parent+string(filepath.Separator)) {
		return "", fmt.Errorf("目标路径越过根目录: %s", target)
	}
	return rel, nil
}

func main() {
	// 这些输入用于说明根目录、子目录和 .. 越界三种结果。
	root := "/srv/app"
	for _, target := range []string{
		"/srv/app/logs/../data",
		"/srv/app",
		"/srv/app/../secret",
	} {
		rel, err := relativeInside(root, target)
		fmt.Printf("target=%q rel=%q err=%v\\n", target, rel, err)
	}
}

这个组合有一个值得保留的好处：Rel 的错误不会被吞掉，越界判断也没有依赖字符串前缀。对根目录本身，调用方可以把 . 映射成“当前目录”，也可以明确禁止它。

这个方案的边界

Clean 和 Rel 都是词法层面的路径处理。一个路径即使被判断为位于根目录下，也可能通过符号链接指向别处；如果业务边界要求考虑真实文件系统对象，就需要在确认文件存在后结合 filepath.EvalSymlinks 再设计检查流程，并处理链接不存在、权限和竞态问题。

另外，根目录校验不是权限控制。最终读写仍要依赖操作系统权限、文件打开模式和业务授权。把这段函数放在输入边界附近，主要价值是让“根目录外的词法路径”尽早失败，而不是替代完整的文件安全设计。

相关问题

为什么不用 strings.HasPrefix？ 因为它不理解路径段，/srv/app2 会错误匹配 /srv/app。使用 Rel 后再检查 .. 段，边界更明确。

Rel 返回错误时能否直接放行？ 不能。错误意味着当前输入无法按预期计算相对路径，应交给调用方记录或拒绝。

Clean 后还需要检查文件是否存在吗？ 需要与否取决于业务；Clean 本身不访问文件系统，也不会替你完成存在性、权限或符号链接检查。