Go io/fs.Sub 为什么不能访问父目录

调用 fs.Sub 后，子文件系统里的 ../README.md 访问失败，并不是 Go 没有找到真实的父目录，而是这个名字根本不属于 fs.FS 的合法路径空间。fs.Sub(fsys, "static") 把 static 变成了新 FS 的根；新 FS 只接受从这棵“新树根”出发的相对路径。

解决办法是保留原始 fsys，需要父级资源时从原始 FS 读取，需要子目录资源时从 subFS 读取。不要试图在子 FS 中用 .. 逃回父级。

官方文档：https://pkg.go.dev/io/fs#Sub

先还原 Sub 后的失败现象

假设资源树如下，static 下放配置，根目录还放着一份说明文件：

root/
├── README.md
└── static/
    └── app.yaml

创建子 FS 后，app.yaml 可以正常读取，但把 ../README.md 交给 fs.ReadFile 会得到非法参数。下面的代码只用于说明路径边界：

package main

import (
	"fmt"
	"io/fs"
	"testing/fstest"
)

func main() {
	// MapFS 把资源树放在内存中，便于说明 FS 的逻辑路径。
	root := fstest.MapFS{
		"README.md":       &fstest.MapFile{Data: []byte("root note")},
		"static/app.yaml": &fstest.MapFile{Data: []byte("name: demo")},
	}

	// Sub 创建以 static 为根的视图，子视图里的 app.yaml 对应原树的 static/app.yaml。
	staticFS, err := fs.Sub(root, "static")
	if err != nil {
		panic(err)
	}

	data, err := fs.ReadFile(staticFS, "app.yaml")
	fmt.Printf("app.yaml: %q, err=%v\n", data, err)

	// .. 不是 fs.FS 的父级访问语法；它违反 ValidPath 的命名规则。
	_, err = fs.ReadFile(staticFS, "../README.md")
	fmt.Printf("../README.md: err=%v\n", err)
}

这里的关键不是底层是否真的存在 README.md，而是 staticFS.Open 收到的名称必须满足 fs.ValidPath。..、以斜杠开头的 /README.md、以斜杠结尾的 app.yaml/ 都不属于标准 FS 名称。

理解子文件系统的根和路径映射

官方定义中，fs.Sub(fsys, dir) 返回的是“以 fsys 的 dir 为根的子树”。当 dir 不是 . 时，普通实现可以把子 FS 的 Open(name) 理解为底层的 fsys.Open(path.Join(dir, name))，并同步处理 ReadDir、ReadFile、ReadLink、Lstat 和 Glob 等操作。

这是一种路径视图，不是把真实目录搬家，也不是给子 FS 增加“向上导航”的能力。可以把它记成：

还有一个容易忽略的边界：创建 Sub 时并不会检查 dir 当前是否存在。真正访问资源时，底层 FS 才可能返回不存在错误；因此不要把 fs.Sub 返回成功理解成目录已经通过了存在性检查。

需要父级资源时保留原始 FS

如果一个组件既要读取 static/app.yaml，又要读取根目录的 README.md，正确的接口设计是同时保留两个视图。原始 FS 负责根级资源，子 FS 负责组件内部资源：

package config

import (
	"fmt"
	"io/fs"
)

// LoadFiles 展示两个 FS 视图的职责：child 只看 static，root 仍能看整个资源树。
func LoadFiles(root fs.FS, child fs.FS) error {
	configData, err := fs.ReadFile(child, "app.yaml")
	if err != nil {
		return fmt.Errorf("读取子目录配置: %w", err) // 保留底层 PathError，方便上层判断原因。
	}

	readme, err := fs.ReadFile(root, "README.md")
	if err != nil {
		return fmt.Errorf("读取根目录说明: %w", err) // 根级路径必须交给原始 FS。
	}

	fmt.Printf("config=%q, readme=%q\n", configData, readme)
	return nil
}

组装时只做一次切分：

// root 是完整资源视图；child 是 static 子树视图。
child, err := fs.Sub(root, "static")
if err != nil {
	return err // dir 参数非法时，尽早把构造错误交给调用方。
}

return config.LoadFiles(root, child)

这样做的好处是访问边界写在接口上：看到 child fs.FS 的函数就知道它不应依赖父级路径；需要根级资源的函数明确接收 root fs.FS。这比在字符串里拼接 ../ 更容易审查，也不会因为换成嵌入资源、内存 FS 或压缩包 FS 而改变语义。

按访问边界选择 FS 设计

遇到“子目录里还要找父级”的需求时，先判断调用关系，而不是修改路径字符串：

最后记住三个判断点：fs.Sub 改变的是调用方看到的根；fs.FS 路径不支持 ..；父级资源应该通过原始 FS 或另一个明确的 FS 视图提供。这样即使底层换成 embed.FS、os.DirFS 或测试用的 fstest.MapFS，代码的边界仍然稳定。

常见追问

为什么 fs.Sub(root, ".") 可以访问根目录？

因为 dir 为 . 时，官方实现直接返回原始 fsys。它不是“从子目录返回父级”，而是根本没有创建更窄的子视图。

能不能把 ../README.md 清理成 README.md 再读取？

不建议。这样会改变调用方请求的资源，可能把越界访问静默变成错误的根级读取。应在接口层选择原始 FS，或由组装代码显式传入需要的另一个视图。