Go io/fs.ValidPath 为什么拒绝带点路径：文件系统入口与清理边界

把用户输入直接交给 fs.ValidPath 时，最容易遇到的结果是："docs/./readme.md" 和 "docs/../readme.md" 都返回 false。这不是它不会清理路径，而是它要先确认传入值已经是 io/fs 约定的“干净相对路径”。

fs.ValidPath 只负责验证，不负责把操作系统路径修成可用于 fs.FS.Open 的名字；先决定路径语义，再清理并验证，才能避免把用户输入误当成文件系统入口。

先复现 ValidPath 的拒绝边界

下面这组输入足以把问题分成三类：已经符合 FS 入口规则的名字、带有清理痕迹的名字，以及本来就属于操作系统路径的名字。

package main

import (
    "fmt"
    "io/fs"
)

func main() {
    samples := []string{
        "docs/readme.md",
        "docs/./readme.md",
        "docs/../readme.md",
        "/etc/hosts",
        "",
        ".",
        "..",
    }
    for _, name := range samples {
        fmt.Printf("%-18q %v\n", name, fs.ValidPath(name))
    }
}

预期能通过的是 docs/readme.md；其余值分别触碰了点段、绝对路径、空值或特殊根目录语义。这里的关键不是记住一张黑名单，而是认清 ValidPath 检查的是 FS 名字的形状。

为什么 path.Clean 不能替代 ValidPath

path.Clean 的职责是把斜杠路径归一化：它会消掉重复斜杠、处理点段，并保留“路径可被继续解释”的结果。验证函数则是在回答另一个问题：这个字符串能不能作为 FS 的入口名。两者顺序混用，就会把原始输入里的意图抹掉。

package main

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

func main() {
    raw := "docs/../private/key.txt"
    cleaned := path.Clean(raw)
    fmt.Println("raw:", raw, "valid:", fs.ValidPath(raw))
    fmt.Println("cleaned:", cleaned, "valid:", fs.ValidPath(cleaned))
}

这个例子里，清理结果是 private/key.txt，它的形状可能合法，但它已经不是原输入所表达的同一个访问意图。若业务不允许用户借助父级段跳到另一个目录，应该先检查原始片段，再决定是否允许清理。

把操作系统路径和 FS 名字分开处理

filepath.Join 面向当前操作系统，分隔符、卷名和绝对路径规则都属于 OS 层；fs.FS.Open 接收的名字则使用正斜杠分隔。一个常见错误是先用 filepath.Join 拼出路径，再把结果原样交给 Open。

如果数据来自 URL、配置文件或归档条目，先把它当作 FS 名字处理：拒绝绝对路径，拒绝空段和父级段，确认 fs.ValidPath 通过后再调用 Open。如果数据来自本地磁盘路径，则先留在 filepath 语义中，不要把 fs.ValidPath 当作通用的目录穿越防护。

一个可复查的入口函数

下面的函数保留原始输入检查，再进入 fs.ValidPath 和 fs.FS.Open。示例没有把所有业务策略塞进标准库函数，调用方仍能清楚看到每个拒绝点。

func openFSFile(fsys fs.FS, name string) (fs.File, error) {
    if name == "" || name == "." || name == ".." {
        return nil, fmt.Errorf("invalid entry name: %q", name)
    }
    for _, part := range strings.Split(name, "/") {
        if part == ".." {
            return nil, fmt.Errorf("parent segment is not allowed: %q", name)
        }
    }
    if !fs.ValidPath(name) {
        return nil, fmt.Errorf("invalid fs path: %q", name)
    }
    return fsys.Open(name)
}

这里的成功状态很具体：函数完成 fs.ValidPath 后才调用 fsys.Open，返回的文件对象对应一个已经通过入口校验的相对名字。读取完毕仍要关闭文件；路径校验不会替代资源生命周期管理。

ValidPath 常见问题与边界

能否用 strings.Replace 全部删掉 ../？

不建议。替换可能把两个原本不同的文件名拼成同一个结果，也可能漏掉编码后再解码的路径。应在明确的路径语义下分段检查，并让最终入口再次通过 fs.ValidPath。

ValidPath 通过就代表一定安全了吗？

不能。它证明的是 FS 名字格式，不证明权限、租户边界或业务授权。真正打开文件时还要检查调用者能否访问该目录和文件。

为什么不用 filepath.Clean？

当目标是 fs.FS 时，path.Clean 与正斜杠语义更贴近；当目标是本地操作系统路径时才使用 filepath。先选对抽象层，比换一个清理函数更重要。

最后用一张检查表收口

• 输入是否明确属于 FS 名字，而不是本地绝对路径？
• 是否在清理前识别并按业务策略处理 ..？
• 清理或拼接后是否再次调用 fs.ValidPath？
• 是否只在校验通过后调用 fsys.Open，并在读取结束关闭文件？

把这四个问题写进测试用例，docs/readme.md、docs/./readme.md、docs/../readme.md 和绝对路径的结果就不会被一次“顺手清理”混在一起。