fstest.MapFS是只读的，因仅实现fs.FS接口，未实现fs.ReadWriteFS，调用os.OpenFile等写操作会返回“operation not supported”错误；它专为http.FileServer的只读HTTP服务测试设计，不支持运行时文件写入或os包全量操作。
testing/fstest 不能直接用于运行时文件操作测试，它只适用于验证 http.FileServer 类型的 HTTP 文件服务逻辑，且仅支持只读场景。
为什么 fstest.MapFS 是只读的、且不支持 os.OpenFile
testing/fstest.MapFS 是一个内存中实现的 fs.FS，但它的底层设计绕过了 os.File 抽象，所有文件内容都以 []byte 形式预加载。这意味着：
- 调用
os.OpenFile("x.txt", os.O_RDWR, 0)会返回*os.PathError，错误信息是"operation not supported" - 任何需要写入、截断、
Seek或文件锁的操作都会失败 - 它不满足
fs.ReadFileFS或fs.GlobFS等接口的完整契约，仅保证fs.ReadDirFS和fs.ReadFileFS的基础读取能力 - 它的主要用途是配合
http.FileServer(http.FS(...))做端到端 HTTP 文件路由测试
如何正确构造 MapFS 并传给 http.FileServer
必须把路径键名写成 Unix 风格（正斜杠），且目录需显式声明为 fs.DirEntry 类型；文件内容用 []byte，权限位建议设为 0444（只读）或 0644（用户可写，但 fstest 不执行写）：
fs := fstest.MapFS{
"index.html": &fstest.MapFile{Data: []byte("<h1>OK</h1>"), Mode: 0644},
"assets/logo.png": &fstest.MapFile{Data: pngBytes, Mode: 0444},
"static/": &fstest.MapFile{Mode: 0755 | fs.ModeDir},
}
handler := http.FileServer(http.FS(fs))
注意："static/" 结尾的斜杠不能省略，否则 http.FileServer 无法识别为目录；Mode 中必须包含 fs.ModeDir 才能被 fs.ReadDir 正确解析。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
遇到 “no such file or directory” 错误的常见原因
即使文件已注册进 MapFS，HTTP 请求仍可能 404，典型原因包括：
- 请求路径带前导
/（如GET /index.html），而MapFS键名不含该前导符 ——http.FS会自动剥离，所以键名写"index.html"即可 - 路径大小写不一致：Windows/macOS 默认不区分大小写，但
MapFS是严格区分的，"Index.html"≠"index.html" - 未启用
http.StripPrefix：若 handler 挂在子路径如/static/下，需先http.StripPrefix("/static", handler)，否则MapFS查找的是"static/index.html"而非"index.html" -
MapFS中缺失index.html且未配置http.ServeContent回退逻辑，导致目录访问失败
什么时候不该用 fstest.MapFS
如果你的代码直接调用 os.Stat、ioutil.WriteFile、os.Create 或依赖 os.File 的系统调用行为，fstest.MapFS 完全无用。此时应：
- 重构代码，接受
fs.FS接口参数（而非硬编码os包函数） - 对真实 I/O 路径使用临时目录 +
os.RemoveAll清理（testing.T.Cleanup配合os.MkdirTemp） - 用
github.com/spf13/afero这类可读写内存 FS 替代，它支持全部os操作语义
fstest 的边界很清晰：它不是通用 mock 文件系统，而是 Go 标准库为验证自身 net/http 文件服务行为定制的轻量工具。越想让它干更多事，越容易掉进“为什么这个方法没效果”的坑里。
