Go语言中fstest.MemMapFS一用就panic，因其返回的fs.File不满足os.File底层要求（如无文件描述符、不支持os.Stat），导致依赖*os.File的代码崩溃；真正解耦需定义带context的Storage接口而非硬套fs.FS。
Go 语言里没有“开箱即用”的可写虚拟文件系统，硬套 fs.FS 或直接传 fstest.MemMapFS 给依赖 *os.File 的代码，大概率 panic 或静默失败。
为什么 fstest.MemMapFS 一用就 panic
它实现了 fs.ReadWriteFS，但返回的 fs.File 不满足 os.File 的底层要求——比如没有文件描述符（fd）、不支持 os.Stat 或 os.Chmod。任何调用 os.OpenFile、日志轮转器、或依赖 file.(*os.File).Fd() 的库都会崩。
-
fs.ReadFile(fsys, "x.txt")✅ 可行，因为它只走fs.FS接口 -
os.Open("x.txt")❌ 不能用，路径是磁盘硬编码，和虚拟 FS 无关 -
os.Stat("x.txt")❌ 失败，必须改用fs.Stat(fsys, "x.txt") -
MemMapFS的ModTime()默认返回零时间，按时间排序的日志归档逻辑会失效
memfs 包能写但得手动收尾
github.com/kevin-cantwell/memfs 返回的 memfs.File 满足 io.ReadWriteSeeker 和 io.Closer，能兼容更多现有代码，但它不是“即插即用”——漏掉 .Close() 就会锁死文件。
- 每次
fs.Create()后必须显式调用.Close()，否则后续fs.Open()会报text file busy -
fs.Create("a/../b.txt")不自动filepath.Clean()，真会建出a/../b.txt这种路径，测试中要提前规整 - 不支持硬链接、
os.Lstat()、os.FileInfo.Sys()，业务若用到就得自己 mockSys()返回值
真正解耦得靠 Storage 接口，不是 fs.FS
fs.FS 是只读契约，os 包根本不可 mock。业务代码如果直接调 os.ReadFile 或硬写路径，测试和内存模拟就永远卡死。
立即学习“go语言免费学习笔记（深入）”；
- 定义自己的
Storage接口，带context.Context，方法如ReadFile(ctx, path)、WriteFile(ctx, path, data, perm) -
FileStat必须是自定义结构体，不能直接返回fs.FileInfo—— S3 实现没法填Mode，内存实现没法填Ino - 生产用
os.DirFS，测试用memfs，线上用对象存储，全靠接口切换，不碰os一行
embed.FS 和 http.FileSystem 是只读安全区
编译期嵌入资源或做静态文件服务时，embed.FS 和 http.FileSystem 是最稳的选择，它们天然只读、无副作用、路径由 fs.ValidPath 安全校验。
-
embed.FS路径必须是字面量，//go:embed assets/*+fs.ReadFile(efs, "assets/config.json") -
http.FileServer(http.FS(fsys))能直接服务embed.FS或fstest.MapFS，不用改路由逻辑 -
fstest.MapFS声明目录必须带结尾斜杠和fs.ModeDir，否则fs.ReadDir找不到子项
最容易被忽略的是：路径合法性校验、时间戳语义、以及 Close() 的调用时机——这三个点不处理，哪怕用了 memfs，测试也可能在并发场景下偶然失败，而不是立即报错。
