Go afero MemMapFs 与 OsFs 测试时有什么区别

在 Go 项目里把文件访问改成 afero.Fs 后，测试代码常见一个误区：看到 NewMemMapFs 能读写，就以为它和 NewOsFs 能覆盖同一类问题。两者都提供文件系统接口，但底层边界不同。MemMapFs 把数据放进进程内存，适合隔离、快速、可重复的逻辑测试；OsFs 直接调用操作系统文件 API，适合检查真实目录、权限、平台行为和磁盘副作用。

官方地址：https://github.com/spf13/afero

选择方法可以记成一句话：要验证“业务代码怎么处理文件”，先用 MemMapFs；要验证“操作系统怎样对待文件”，再用 OsFs。成熟项目通常两者都用，而不是让其中一个替代另一个。

先从现象判断：测试通过，为什么上线后仍失败

如果测试只注入 afero.NewMemMapFs()，它主要证明路径拼接、创建、读取、写入、重命名和删除等业务逻辑可以在一个隔离文件系统里完成。它不会把测试文件写到真实磁盘，也不会自然暴露真实目录的权限、挂载方式、大小写规则或平台差异。

相反，afero.NewOsFs() 使用的是操作系统提供的文件能力。测试可能因为目录不存在、权限不足、文件被占用或平台语义不同而失败，但这些失败正是集成测试要捕获的环境契约。排查时先问清楚失败属于哪一层：如果是业务分支，优先看 MemMapFs；如果是环境和系统交互，必须让 OsFs 参与。

第一层检查：两个构造函数把请求送到哪里

Afero 官方实现中，OsFs 的方法直接转调 os.Create、os.Open、os.Remove 等函数；MemMapFs 则维护进程内的数据映射，并用读写锁保护内部状态。因此第一条选择规则很稳定：需要磁盘行为就用 OsFs，需要隔离状态就用 MemMapFs。

package storage_test

import (
    "testing"

    "github.com/spf13/afero"
)

func TestBackendChoice(t *testing.T) {
    // MemMapFs 只存在于当前进程，适合每个测试独立准备数据。
    memoryFS := afero.NewMemMapFs()

    // OsFs 把调用交给操作系统，路径和权限由真实环境决定。
    osFS := afero.NewOsFs()

    if memoryFS.Name() == osFS.Name() {
        // 这里仅用于说明判断边界，实际业务不应依赖 Name 做类型分支。
        t.Fatal("two backends should remain distinguishable")
    }
}

这个例子不应被理解为“在生产代码中判断后端类型”。更合适的做法是让业务函数只接收 afero.Fs，由测试或组装层决定注入哪个实现。这样一份业务逻辑可以被两种测试后端复用。

第二层检查：同一段业务代码，两种测试边界

把创建目录、保存内容和读取内容封装成一个小函数，可以清楚地看到两种后端的职责并没有改变；改变的是文件最终落点和测试想证明的事情。

package storage_test

import (
    "fmt"

    "github.com/spf13/afero"
)

func SaveReport(fs afero.Fs, name string, body []byte) error {
    // 业务函数只依赖抽象，不关心文件来自内存还是磁盘。
    if err := fs.MkdirAll("reports", 0o755); err != nil {
        return fmt.Errorf("create reports directory: %w", err)
    }

    // 父目录已明确创建，WriteFile 只负责写入目标文件。
    if err := afero.WriteFile(fs, "reports/"+name, body, 0o644); err != nil {
        return fmt.Errorf("write report: %w", err)
    }
    return nil
}

func TestSaveReportInMemory(t *testing.T) {
    // 单元测试使用内存后端，测试结束后不需要删除磁盘临时文件。
    fs := afero.NewMemMapFs()
    if err := SaveReport(fs, "unit.txt", []byte("unit")); err != nil {
        t.Fatal(err)
    }
}

func TestSaveReportOnDisk(t *testing.T) {
    // 集成测试使用临时目录，验证真实文件系统的路径和权限交互。
    dir := t.TempDir()
    fs := afero.NewBasePathFs(afero.NewOsFs(), dir)
    if err := SaveReport(fs, "integration.txt", []byte("integration")); err != nil {
        t.Fatal(err)
    }
}

这里的 BasePathFs 只是把 OsFs 的访问范围收拢到测试临时目录，仍然属于真实操作系统文件测试。它不能把 OsFs 变成 MemMapFs，也不能替代对权限和平台差异的验证。

第三层检查：哪些证据说明 MemMapFs 不够

下面几类失败通常不是“MemMapFs 有问题”，而是测试边界没有覆盖到真实文件系统：

• 业务依赖目录的真实权限、只读挂载或用户身份；
• 需要确认符号链接、文件锁、路径大小写或平台特有语义；
• 要验证文件是否真的出现在指定目录，或者后续进程能否读取；
• 要检查磁盘空间、文件名限制、清理动作和与外部工具的交互。

这时应增加 OsFs 集成测试，并把临时目录、权限、清理和平台条件写清楚。不要为了让测试稳定而把这类场景全部替换成 MemMapFs，否则测试可能只证明了抽象层能工作，却没有证明部署环境能工作。

第四层检查：哪些证据说明 OsFs 不适合单元测试

如果每个小测试都创建真实目录、写入大量 fixture，再处理并发清理，那么失败原因会混入磁盘状态、权限和机器环境，测试速度也会变慢。此时把稳定的文件业务分支改用 MemMapFs，通常能获得更清晰的失败证据：

反向验证：组合使用，而不是二选一

一个实用的测试组合是：先用 MemMapFs 覆盖大多数纯文件逻辑，再用少量 OsFs 测试锁定真实环境契约。若两组测试结果不一致，不要立即修改业务代码，先检查是不是测试目标不同：内存测试验证的是抽象接口上的逻辑，磁盘测试验证的是操作系统边界。

func TestSameContract(t *testing.T) {
    cases := []struct {
        name string
        fs   afero.Fs
    }{
        // 轻量逻辑覆盖放在内存后端。
        {name: "memory", fs: afero.NewMemMapFs()},
        // 少量真实环境覆盖放在临时目录后端。
        {name: "os", fs: afero.NewBasePathFs(afero.NewOsFs(), t.TempDir())},
    }

    for _, tc := range cases {
        t.Run(tc.name, func(t *testing.T) {
            // 两个后端调用同一份业务契约，差异只由底层实现产生。
            if err := SaveReport(tc.fs, "report.txt", []byte("ok")); err != nil {
                t.Fatal(err)
            }
        })
    }
}

最后的选择清单

1. 只验证业务文件逻辑、错误分支和大量组合输入：先选 MemMapFs。
2. 要验证真实目录、权限、平台语义或磁盘副作用：补充 OsFs。
3. 要避免集成测试污染工作区：用 t.TempDir() 包裹 NewOsFs()。
4. 业务函数接收 afero.Fs，不要在函数内部偷偷固定某个后端。
5. 两类测试都通过，才更接近“抽象逻辑正确且部署环境可用”的结论。

常见追问

MemMapFs 会把测试文件写到项目目录吗？

不会。它维护的是进程内的内存数据，测试结束后随进程状态释放；但它仍然只能模拟 afero 支持的文件操作，不能代表真实磁盘的全部语义。

OsFs 能不能直接用于所有单元测试？

可以调用，但不建议把所有单元测试都绑定到它。真实磁盘会引入权限、路径、清理和并发因素，适合少量集成覆盖，不适合替代快速隔离的逻辑测试。

为什么要让业务函数接收 afero.Fs？

因为依赖注入后，测试只需替换后端，不必复制业务逻辑。这样 MemMapFs 和 OsFs 可以针对不同边界复用同一个函数契约。