我在处理“用户选择一个文件，再把它转换成工作目录下的相对路径”时，最容易踩的坑不是 filepath.Rel 本身，而是把返回字符串误当成了安全结论。更稳妥的做法是：先处理 Rel 的错误，再只把结果为 .. 或以 .. 加路径分隔符开头的情况判为越出基准目录。
官方文档：https://pkg.go.dev/path/filepath#Rel
filepath.Rel(basePath, targPath) 计算的是词法上的相对路径。它不会因为目标文件暂时不存在就失败，也不会自动解析符号链接；因此这篇只解决“路径字符串相对基准目录向上走了多少层”，不把它扩大成权限或真实文件系统校验。
调用`filepath.Rel(basePath, targetPath)`获取相对路径后，如果返回的相对路径前缀为`..`，就代表目标路径已经越过了设定的根目录边界，不符合访问规则。
先看懂 Rel 返回的三个结果
Rel 返回 rel 和 error。当两个路径可以在当前操作系统规则下计算时，rel 是把它拼回 basePath 后与目标路径词法等价的结果；目标在基准目录下面时通常是 reports/today.csv，目标在上级目录时则可能是 ../shared/today.csv。
如果路径位于不同盘符、需要无法确定的当前工作目录，或者输入的绝对性不匹配，应该先处理错误，不能继续拿空字符串或半成品结果做目录判断。
package main
import (
"fmt"
"path/filepath"
)
func main() {
base := "/srv/app/data"
target := "/srv/app/shared/report.csv"
// Rel 只计算词法相对路径，不读取目标文件内容。
rel, err := filepath.Rel(base, target)
if err != nil {
// 跨卷或路径形式不兼容时，必须停止后续判断。
fmt.Println("无法计算相对路径:", err)
return
}
fmt.Println("relative path:", rel)
}
这个例子得到的 ../shared/report.csv 说明目标相对 base 向上退了一层，但它本身不是文件系统访问授权。把“能算出相对路径”和“允许访问目标”分成两个判断，后面更容易替换策略。
只识别完整的 .. 路径段
判断越界时，不能写成 strings.HasPrefix(rel, "..")。文件名 ..tmp 也会满足这个前缀，却没有向父目录移动。应当匹配完整路径段：结果等于 ..，或者以 .. 加当前系统分隔符开头。
func escapesBase(rel string) bool {
// 单独的 .. 表示目标正好是基准目录的父目录。
if rel == ".." {
return true
}
// 只有 .. 后面紧跟路径分隔符，才表示继续从父目录向下走。
return strings.HasPrefix(rel, ".."+string(filepath.Separator))
}
这里用的是 filepath.Separator，所以判断会跟随目标操作系统的路径分隔符。../shared 属于越界，reports/../today.csv 在 Rel 处理后的结果不会以 .. 开头，而 ..tmp 仍然是普通名称。
把计算和分类放进一个函数
在实际代码里，我会让函数同时返回“是否越出”和错误，避免调用方忘记处理 Rel 失败。下面的返回值约定是：err != nil 表示无法比较，outside == true 表示词法结果已经离开基准目录。
package pathcheck
import (
"path/filepath"
"strings"
)
// OutsideBase 判断 target 的词法相对路径是否走到了 base 外部。
func OutsideBase(base, target string) (bool, error) {
// 先让 filepath.Rel 处理清理、分隔符和路径形式差异。
rel, err := filepath.Rel(base, target)
if err != nil {
// 跨盘符等情况没有可靠的相对结果，交给调用方决定降级策略。
return false, err
}
// 必须匹配独立的 .. 路径段，避免把 ..tmp 当成父目录。
outside := rel == ".." || strings.HasPrefix(rel, ".."+string(filepath.Separator))
return outside, nil
}
常见结果可以这样理解：
| rel 结果 | 词法判断 | 原因 |
|---|---|---|
images/logo.svg | 目录内 | 没有从基准目录向上走 |
.. | 目录外 | 目标正好位于基准目录的父目录 |
../shared/a.txt | 目录外 | 结果以完整的 .. 段开头 |
..tmp | 目录内 | 只是名称以两个点开头 |
这个判断不能替代符号链接和权限策略
filepath.Rel 的结论是词法结论：它比较输入字符串经过路径规则处理后的关系。即使结果没有 ..，路径中的符号链接也可能把实际访问引向别处；同样，结果带有 .. 也不代表一定应该拒绝，业务可能允许访问共享目录。
因此在文件上传、归档解包或插件目录这类场景中，可以把 OutsideBase 当作第一层路径分类器，随后再按业务需要补充符号链接解析、打开文件时的权限控制和并发策略。不要把一个布尔值包装成“已经安全”的结论。
我最后会保留这四个检查点：
- 先判断
filepath.Rel的错误，再读取相对结果。 - 只匹配完整的
..路径段，不做宽松字符串前缀判断。 - 把
..tmp、同目录的.和跨盘符错误分开处理。 - 明确这是词法路径判断，需要更强保证时另加文件系统策略。
相关问题：
filepath.Rel会读取文件或解析符号链接吗？不会，它主要处理路径字符串；符号链接需要单独解析。- 为什么不能只判断结果是否包含
..？因为普通文件名也可能包含两个点，必须按完整路径段判断。 - 返回错误时能不能把目标当作目录外？不要替调用方做这个决定；错误可能来自跨盘符或路径形式不兼容，应按业务策略显式处理。
Go 测试发现数据竞争为什么不等于测试失败原因 
