Go io/fs.Sub 传入文件路径为什么不能当成子目录

fs.Sub 用于把某个目录下的子树作为新的文件系统视图。普通文件没有可继续访问的子项，因此不能把文件路径当作目录根来列目录或读取下级名称。修复时应把文件的父目录传给 Sub，再用相对于新根的文件名访问。还要注意：Sub 返回 nil 错误，并不保证根对象存在且是目录；通用包装器可能到实际访问时才暴露问题。

官方地址：https://pkg.go.dev/io/fs

问题现场：把文件设成根后，目录访问失败

假设原文件系统包含 assets/settings.json。读者想减少重复路径，于是把 assets/settings.json 整体交给 Sub，再调用 ReadDir 查看新根。这里混淆了两种需求：直接读一个文件，与建立包含该文件的目录视图。

如果只是读取内容，直接调用 fs.ReadFile，传入原始文件系统和完整的内部相对路径即可。若后续还有其他 assets 下的文件要读，就建立 assets 子树，在新视图中使用 settings.json。不要给文件名追加斜杠来伪装目录；那只会引入另一种路径问题。

// base 是现有 fs.FS，assets 是目录。
sub, err := fs.Sub(base, "assets")
if err != nil {
    return err
}
// 新视图中的路径已经相对于 assets，不重复写该前缀。
data, err := fs.ReadFile(sub, "settings.json")
if err != nil {
    return err
}
_ = data // 交给后续配置解析逻辑。

初步判断：路径合法，不代表对象是目录

io/fs 使用斜杠分隔的文件系统内部路径。路径语法检查回答“名字是否符合接口约定”，目录属性检查回答“这个名字指向什么对象”。assets/settings.json 可以是语法合法的名字，但其对应对象仍可能是文件，甚至尚不存在。

根名称用点号表示。对 Sub 返回的视图调用 fs.ReadDir(sub, ".")，是在要求列出这个视图的根；如果包装器背后的根其实是文件，列目录这一操作就没有成立的基础。

动手验证：使用内存文件系统看清错误阶段

下面的完整示例使用 fstest.MapFS 提供固定数据。openOnly 只暴露 Open 方法，刻意隐藏其他扩展接口，使 Sub 使用通用包装逻辑，避免示例行为依赖某个实现自己的 Sub 方法。本文没有运行此代码，下面说明的是接口与实现所决定的预期行为，不是实测输出。

package main

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

type openOnly struct {
    base fs.FS
}

func (f openOnly) Open(name string) (fs.File, error) {
    return f.base.Open(name)
}

func main() {
    // 固定内存数据，不依赖机器上的文件路径。
    base := openOnly{base: fstest.MapFS{
        "assets/settings.json": &fstest.MapFile{
            Data: []byte("{}"),
        },
    }}

    // 路径合法，通用包装器的构造不负责确认目录属性。
    bad, err := fs.Sub(base, "assets/settings.json")
    if err != nil {
        fmt.Println("构造失败:", err)
        return
    }
    _, err = fs.ReadDir(bad, ".")
    fmt.Println("文件根列目录:", err)

    // 选择目录作为根，再读取相对文件名。
    good, err := fs.Sub(base, "assets")
    if err != nil {
        fmt.Println("构造目录视图失败:", err)
        return
    }
    data, err := fs.ReadFile(good, "settings.json")
    if err != nil {
        fmt.Println("读取配置失败:", err)
        return
    }
    fmt.Println("配置字节数:", len(data))
}

这个例子的重点是定位错误属于哪次调用，而非匹配某一条错误字符串。换成操作系统文件系统、自定义 FS 或其他扩展实现后，错误文本和报错时机可能不同。业务不应依赖“必须在 Sub 那一行失败”的假设。

定位原因：Sub 既有通用包装，也有接口委托

官方实现对合法名字检查后，若根为点号，会返回原文件系统；若对象实现 SubFS，则委托它的 Sub 方法；其他情况建立一个保存原文件系统和目录前缀的包装器。通用包装器访问名称时，将其映射回原文件系统中对应的路径。

因此构造一个视图不等于提前扫描目录。文件路径被存成前缀后，视图的根可能映射回该普通文件，而读取根下的 child.txt 则会要求底层访问类似“普通文件名/child.txt”的对象。这说明选错的是根的语义，不能靠换一个子文件名补救。

自定义 SubFS 可以有自己的构造检查，调用者应尊重它返回的实际错误。通用辅助函数的说明并不授权把所有底层实现的错误时机强行统一，也不意味着需要写一个忽略错误的适配层。

修复方案：需要目录前提时显式检查

若初始化阶段就必须确认新根是目录，可以在建立视图之后用 fs.Stat 查询点号，检查 IsDir，并在失败时返回带上下文的错误。这个函数用于表达业务前提，不是替代每次访问的错误处理。

// 本函数所在文件需要导入 fmt 和 io/fs。
func directoryView(base fs.FS, root string) (fs.FS, error) {
    sub, err := fs.Sub(base, root)
    if err != nil {
        return nil, fmt.Errorf("建立子树 %q: %w", root, err)
    }
    info, err := fs.Stat(sub, ".")
    if err != nil {
        return nil, fmt.Errorf("查询子树根 %q: %w", root, err)
    }
    if !info.IsDir() {
        return nil, fmt.Errorf("子树根 %q 不是目录", root)
    }
    return sub, nil
}

检查与使用之间底层对象仍可能改变，尤其是可变文件系统。即便初始化成功，后续 ReadFile、ReadDir 或 Open 仍应检查自己的错误。若直接 Open 获得文件句柄，使用完后由持有者关闭；Sub 返回的是 FS 视图，不是一个已经打开、需要调用 Close 的目录句柄。

验证结果：应检查行为，不绑定报错文案

读者可以用目录根、普通文件根和不存在的根分别观察。正确目录根应能访问相对名称；普通文件不应通过目录属性前提；不存在的根应在实际查询或访问时报告失败。非法内部路径则应按路径约定处理。这些是自行检查时的预期分类，不是本文执行记录。

常见问题

文件根的 Open(".") 偶尔能成功，是否证明它可当目录？不能。打开文件与列出目录是不同能力，应查看对象属性和具体操作结果。

新视图里还能传 assets/settings.json 吗？如果新根已经是 assets，这会重复前缀。应使用 settings.json。

只想隐藏前缀是否必须用 Sub？需要给下游提供统一相对根时它很方便；只读取单个文件时，直接 ReadFile 更简单。

遇到这个问题，先确认目标是目录还是文件，再区分构造与访问的错误位置。用目录建立子树、以新根解释相对名字，才能让后续文件操作符合预期。

参考：Go 官方 fs.Sub 文档；子树包装器官方实现。