afero.memmapfs 不能直接测文件存在性判断，因其不模拟系统级路径解析，如 fs.stat("./config.yaml") 可能 panic，需先用 filepath.clean() 规范路径。
为什么 afero.MemMapFs 不能直接测文件存在性判断？
因为 MemMapFs 默认不模拟系统级的路径解析行为，比如 os.Stat 对相对路径、.. 或符号链接的处理和真实 fs 不一致。你写 fs.Stat("config.yaml") 能过，但换成 fs.Stat("./config.yaml") 或 fs.Stat("../etc/config.yaml") 就可能 panic 或返回 nil 错误，而真实文件系统里这俩通常等价。
- 测试前统一用
filepath.Clean()规范路径，再传给afero操作 - 避免在测试中依赖
..跳转逻辑；如需模拟多层目录结构，显式fs.MkdirAll("etc/conf", 0755) - 若必须测路径解析，改用
afero.NewOsFs()+ 临时目录（但失去纯内存隔离优势）
如何让 afero.Afero 实例支持读写权限校验？
afero.Afero 包装器默认忽略权限位（mode），所有文件都“可读可写”。比如 fs.Chmod("file.txt", 0400) 成功执行，但后续 fs.WriteFile 仍能写入——这和真实 os 行为不符，容易掩盖权限 bug。
- 用
afero.NewReadOnlyFs(fs)包一层来强制只读，适合测“不该写”的场景 - 若要细粒度控制，自己封装一个
PermFs类型，重写Open和Create，根据预设 map 查路径对应 mode 并拒绝写操作 - 注意：Go 1.20+ 的
io/fs接口已将权限作为fs.FileInfo.Mode()返回，但afero的Stat默认不暴露真实 mode，得靠自定义FileInfo实现
afero.WriteFile 返回成功，但后续 ReadFile 报 no such file？
典型原因是没用对 fs 实例——你在测试里 new 了一个 afero.MemMapFs，但业务代码里用的是全局变量或单例，两者不是同一个对象。或者更隐蔽的情况：用了 afero.NewOsFs() 却忘了清理临时文件，上一次测试写入的文件残留干扰了本次。
- 确保测试函数内创建的
fs实例，100% 透传到被测函数（通过参数注入，别用包级变量） - 避免在测试中混用
afero.NewOsFs()和MemMapFs；前者要手动os.RemoveAll(tmpDir)，后者不用 - 加一句
_, err := fs.Stat("expected.txt"); if os.IsNotExist(err) { ... }在WriteFile后立刻验证，比等后续读取失败再排查更快
Mock 多个不同行为的文件系统（比如一个只读、一个带延迟）
afero 本身不提供“行为策略”抽象，它只是把操作转发给底层 fs。想实现差异化行为（如模拟网络延迟、随机失败），得自己包装 afero.Fs 接口，而不是依赖现成类型。
立即学习“go语言免费学习笔记（深入）”；
- 写一个结构体，嵌入
afero.Fs字段，然后重写Open方法：内部 sleep 100ms 再调用原fs.Open - 如果要模拟随机 IO 失败，用
rand.Float64() 控制 10% 概率返回 <code>&os.PathError{Op: "open", Path: name, Err: syscall.EIO} - 别试图给
MemMapFs打补丁加 delay——它本质是 map 操作，加 sleep 只会让测试变慢，且无法覆盖真实磁盘 IO 的并发竞争场景
真正难的不是 mock 本身，而是搞清你要测的是“业务逻辑对 fs 接口的调用顺序”，还是“fs 在异常下的状态一致性”。前者用 MemMapFs 足够，后者得结合 io/fs 的 FS 接口自己造可断言的 spy 实现。
