Go testing/fstest理解测试文件系统的链接边界的设计说明

我第一次把内存文件系统接进测试时，最容易混淆的是“链接本身”和“链接指向的文件”：Open 读到的是目标内容，Lstat 描述的却应该是链接节点。testing/fstest 的设计正好把这条边界保留下来。它适合检查一个 fs.FS 实现是否遵守文件系统契约，但不应该被当成真实磁盘行为的全量模拟。

官方地址：https://pkg.go.dev/testing/fstest

先把普通文件、链接和链接目标分开

fstest.MapFS 是一个内存中的 fs.FS，键是路径，值是 *fstest.MapFile。普通文件把正文放进 Data；符号链接则把目标路径放进 Data，并给 Mode 加上 fs.ModeSymlink。这不是把目标文件内容复制一份，而是明确告诉测试系统这里有一个链接节点。

package fstestdemo

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

func TestLinkBoundary(t *testing.T) {
    files := fstest.MapFS{
        "docs/readme.txt": &fstest.MapFile{
            Data: []byte("content of the real file"), // 普通文件的 Data 是文件内容。
        },
        "docs/current": &fstest.MapFile{
            Data: []byte("docs/readme.txt"), // 链接的 Data 是目标路径，不是目标内容。
            Mode: fs.ModeSymlink,             // 用 ModeSymlink 保留链接节点语义。
        },
    }

    if err := fstest.TestFS(files, "docs/readme.txt", "docs/current"); err != nil {
        t.Fatal(err) // 让 fstest 报告 FS 契约中发现的第一个问题。
    }
}

用 TestFS 检查文件系统契约而不是模拟运行结果

fstest.TestFS(fsys, expected...) 会遍历整个文件树，打开并检查每个文件的基本行为。传入 expected 时，文件系统至少要包含这些路径；不传 expected 则表示期望它为空。它还要求测试期间 fsys 不发生并发变化。

链接边界要特别注意：TestFS 不跟随符号链接。如果文件系统实现了 fs.ReadLinkFS，它会进一步检查链接的 Lstat 信息。也就是说，TestFS 关注的是“这个 FS 是否正确描述了链接”，而不是替你验证目标文件内容是否被某个业务流程读取。

因此，expected 列表应该写成测试契约，而不是把所有可能的路径都塞进去。比如上面的测试需要声明 docs/current 这个链接节点，也要声明 docs/readme.txt 这个真实文件；如果你的实现故意只暴露链接节点，就不要在 expected 中虚构目标路径。

用 Lstat、ReadLink、Open 分别验证三条路径

我通常会把三种断言写在一起，这样失败时能立刻看出是链接元数据、目标文本还是跟随打开出了问题：

func checkLink(t *testing.T, files fstest.MapFS) {
    t.Helper()

    info, err := files.Lstat("docs/current")
    if err != nil {
        t.Fatal(err) // Lstat 失败表示链接节点本身不可见。
    }
    if info.Mode()&fs.ModeSymlink == 0 {
        t.Fatalf("mode=%v: want symlink", info.Mode()) // 不要用普通文件断言替代链接断言。
    }

    target, err := files.ReadLink("docs/current")
    if err != nil {
        t.Fatal(err) // ReadLink 只确认目标路径文本，不读取目标文件。
    }
    if target != "docs/readme.txt" {
        t.Fatalf("target=%q: want docs/readme.txt", target) // 目标必须与 MapFile.Data 一致。
    }

    data, err := fs.ReadFile(files, "docs/current")
    if err != nil {
        t.Fatal(err) // ReadFile 通过 Open 语义读取，通常会跟随链接。
    }
    if string(data) != "content of the real file" {
        t.Fatalf("data=%q: want target content", data) // 这里断言的是目标文件内容。
    }
}

这三条断言不要合并成“能读到内容就算通过”。Lstat 不跟随链接，ReadLink 返回目标路径，Open 才进入跟随语义；少掉其中一条，测试可能掩盖链接被错误地当成普通文件的问题。

处理路径合法性、并发修改和 MapFS 规模边界

最后一层是测试环境本身。fs.FS 使用斜杠分隔的相对路径，测试数据应避免把操作系统路径分隔符、绝对路径和 .. 混进键名。父目录通常可以不写，MapFS 会在需要时合成；但要精确控制空目录或目录元数据时，应显式放入带 fs.ModeDir 的 MapFile。

MapFS 的操作直接读取 map，所以不要在另一个 goroutine 中增删文件。目录打开或读取还要遍历整个 map，官方文档建议它只用于几百个条目以内的测试数据。数据量更大、需要并发读写或必须复现真实文件系统权限时，应换成更接近目标环境的 FS 实现，而不是继续扩大 MapFS。

相关问题

MapFS 为什么不需要手写每一级父目录？ 普通文件的父目录会在需要时合成；只有空目录或需要精确控制目录元数据时，才需要显式的目录条目。

TestFS 能替代真实磁盘测试吗？ 不能。它适合检查 fs.FS 契约和链接边界；权限、并发、文件锁和大目录性能仍应在目标文件系统中单独验证。

把“链接自身”“链接目标”和“跟随读取”拆成三种断言后，testing/fstest 的边界就清楚了：用 TestFS 做整体契约检查，用 Lstat/ReadLink/Open 补齐你真正关心的语义，MapFS 只承担小而稳定的内存测试数据。