fstest.MapFS 是只读的，不能写入，调用 WriteFile 等写操作会 panic：“not implemented”，因其仅实现 fs.FS 而非 fs.ReadWriteFS，底层为只读 map 封装，无写逻辑；正确用途是验证只读消费路径（如 http.FileServer、template.ParseFS）；需读写时应换用 memfs 或 afero。
fstest.MapFS 是只读的，不能写入。任何尝试调用 os.WriteFile、fs.Create 或 OpenFile(..., os.O_WRONLY, ...) 的操作都会 panic：“not implemented”。这不是 bug，是设计使然。
为什么 fstest.MapFS 调用 WriteFile 会 panic
它只实现了 fs.FS 接口，没实现 fs.ReadWriteFS。底层是 map[string]fs.FileInfo 加一层封装，没有文件句柄、没有缓冲区、没有写逻辑。你传给 os.WriteFile 的 fs.FS 实例，会被 os 包内部转成 fs.ReadFileFS 或 fs.ReadDirFS，但一旦涉及写，就无路可走。
- 常见错误现象：
panic: not implemented出现在os.WriteFile(fs, "x.txt", ...)或fs.OpenFile("x.txt", os.O_CREATE|os.O_WRONLY, 0644) - 你以为在“写内存”，其实连内存都没碰——它连
Write方法都没暴露 - 如果你用
embed.FS做对比，会发现两者语义一致：都是编译期静态、运行时只读
fstest.MapFS 的正确使用场景
它唯一靠谱的用途，是验证「只读消费路径」是否兼容标准 fs.FS 接口。比如：
-
http.FileServer(http.FS(fs))—— 启一个只读静态服务 -
template.ParseFS(fs, "*.html")—— 解析模板文件 -
text/template.ParseFS或html/template.ParseFS - 替代
embed.FS做单元测试，例如配置加载器只调用fs.ReadFile
构造时预置数据没问题：fstest.MapFS{"config.yaml": &fstest.MapFile{Data: []byte("...")}}，但这不是“写”，只是初始化 map 键值对。
立即学习“go语言免费学习笔记（深入）”；
需要读写双向操作？别硬刚 fstest.MapFS
Go 标准库不提供可写内存 FS。必须换方案：
-
github.com/kevin-cantwell/memfs：纯标准库依赖，返回*memfs.FS，支持Create、Remove、Open、Stat，且实现了fs.ReadWriteFS和fs.StatFS -
github.com/spf13/afero：更成熟，有 memory、Os、readonly 等多种 backend，API 更贴近os，但引入额外依赖 - 自己组合：用
memfs.New()+ 封装一层适配器，把fs.FS参数桥接到可写实例上（注意别混用os.Open和fs.Open）
示例（memfs）：
fs := memfs.New()
f, _ := fs.Create("a.txt")
f.Write([]byte("hello"))
f.Close()
data, _ := fs.ReadFile("a.txt") // 能读到注意：它的 Stat().ModTime() 默认是零值，如果被测代码依赖修改时间，得手动 patch memfs.FileInfo。
容易被忽略的关键细节
很多人卡在“为什么我 mock 了 FS，但 os.WriteFile 还是去写磁盘”。答案是：你没替换掉 os 包的底层行为。os.WriteFile 不接受 fs.FS 参数，它只认真实路径。要让它走内存，必须改用 fs.WriteFile（Go 1.16+），或把被测函数改成接收 fs.FS 参数并用 fs.ReadFile/fs.WriteFile 操作。
换句话说：fstest.MapFS 不是用来“替代 os 包”的，而是用来“替代磁盘路径 + 验证 FS 接口契约”的。真要模拟读写闭环，接口抽象这一步绕不开。
