afero 的 memmapfs 不能直接当“真实文件系统”用，因其纯内存实现，缺乏路径解析、权限模拟、链接支持及自动创建父目录等 unix 语义，且不处理 ../.、不触发系统调用，导致 os.stat 或 filepath.walkdir 等调用易 panic 或返回空结果。
为什么 Afero 的 MemMapFs 不能直接当“真实文件系统”用
Afero 的 MemMapFs 是纯内存映射，没有路径解析、权限模拟、硬链接/软链接支持，也不触发系统调用。它只响应你显式调用的 Open、WriteFile 等方法，不会自动创建父目录，也不会按 Unix 语义处理 .. 或 . —— 所以一旦你的代码里有 os.Stat("a/b/c.txt") 或依赖 filepath.WalkDir，直接换 MemMapFs 很可能 panic 或返回空结果。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 用
afero.NewOsFs()做基准测试，确认原逻辑在真实 fs 下行为无误 - 若需路径遍历能力，改用
afero.NewReadOnlyFs(afero.NewMemMapFs())不解决问题，应切换为afero.NewBasePathFs(afero.NewMemMapFs(), "/")并手动预置目录结构 - 所有
filepath.Join结果必须先fs.MkdirAll(filepath.Dir(path), 0755)，MemMapFs不会自动创建中间目录
如何让 io/fs.FS 接口和 Afero 共存而不翻车
Go 1.16+ 引入 io/fs.FS，但 Afero 的 afero.Fs 是独立接口，二者不兼容。强行类型断言或包装容易漏掉 ReadDir、Open 返回值的细节差异，尤其在使用 embed.FS 或 http.FileServer 时会静默失败。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 不要试图把
afero.Fs直接转成io/fs.FS；用afero.ToIOFS(fs)（Afero v1.9+）做转换，它会桥接大部分方法 -
afero.ToIOFS返回的io/fs.FS不支持io/fs.ReadDirFS的全部能力，若代码调用了fs.ReadDir，需确保底层是afero.MemMapFs（它实现了ReadDir），而非afero.OsFs - 测试中混用时，避免对同一
MemMapFs实例并发写入——它不是线程安全的，没加锁，多 goroutine 写同路径会丢数据
Copy 和 Walk 在内存文件系统里为什么总少几层目录
Afero 的 afero.Copy 默认不递归创建目标父目录，afero.Walk 则默认跳过子目录（除非显式处理 fs.IsDir）。这两个行为在 MemMapFs 中会被放大：因为没真实目录树可“发现”，一切依赖你手动初始化。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 复制前先
fs.MkdirAll(filepath.Dir(dst), 0755)，别指望Copy自动搞定 -
Walk时别只看info.IsDir()就 return；对目录要显式调用fs.ReadDir，否则子项永远不会被访问到 - 如果用
afero.WalkFunc，注意它的path参数是相对路径，而MemMapFs的 key 是绝对路径字符串（如"a/b/c.txt"），别拿filepath.Base(path)当唯一标识去查
测试中替换全局 os 函数的危险操作
有人会想把 os.Open、os.WriteFile 全局替换成 Afero 版本，这是错的。Go 标准库内部（比如 log、net/http、plugin）会直调 syscall，绕过你的 hook；而且函数变量替换在测试并发时极易污染其他 test case。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 永远通过构造函数注入 fs：把
fs afero.Fs作为 struct 字段或函数参数，而不是依赖包级变量 - 避免 monkey patch
os，Afero 提供afero.NewOsFs()已足够覆盖生产环境，测试时只换实例不换调用点 - 如果非要用
os兼容层，用afero.NewOsFs().(afero.Fs)而不是自己实现os.File子类——后者几乎无法正确模拟Seek、Readdir等状态机行为
真正难的是路径边界：MemMapFs 对 /a/../b 不做规范化，filepath.Clean 必须由你显式调用；还有 symlink 的 target 是字符串还是另一个 File，Afero 默认不处理。这些细节不写测试用例根本暴露不出来。
