Go标准库无开箱即用可写内存文件系统；fstest.MapFS只读，写操作直接panic；memfs包支持完整写能力但需注意路径处理、Close调用及时间戳等细节；应定义最小契约接口而非硬套标准库。
Go 语言标准库没有开箱即用的可写内存文件系统，直接用 fstest.MapFS 或 embed.FS 写入会 panic；必须选对抽象层级，否则运行时崩溃或静默失败。
为什么 fstest.MapFS.WriteFile 会 panic
fstest.MapFS 是只读实现，它满足 fs.FS 接口但不提供写能力。所有写操作（如 fs.WriteFile、fs.Create）底层都调用未实现的空方法，直接 panic。
- 调用
fs.WriteFile(fsys, "x.txt", data, 0644)→ panic: "not implemented" - 即使构造时传了
"x.txt": &fstest.MapFile{Data: ...}，也无法修改内容或新增路径 - 它连
fs.Open返回的fs.File都是一次性对象：第二次ReadAll就 panic - 路径必须是字面量，
"./a.txt"或"a/../b.txt"均无效
用 memfs 包实现真正可写的内存 FS
github.com/kevin-cantwell/memfs 是目前最贴近真实 os.File 行为的内存实现，支持 Create、MkdirAll、RemoveAll、Chmod，返回的 memfs.File 满足 io.ReadWriteSeeker 和 io.Closer。
- 必须显式调用
.Close()，否则后续Open可能因“文件被占用”失败 - 路径不自动
filepath.Clean()：fs.Create("a/../b.txt")真的建出a/../b.txt目录结构，测试中需预处理 - 不支持硬链接、符号链接、UID/GID —— 若业务调用
os.Lstat或解析FileInfo.Sys()，得自己 mockSys()返回值 -
ModTime()默认返回零时间，依赖时间戳排序（如日志轮转）的逻辑需 patchFileInfo
别硬套标准库接口，定义自己的 Storage 接口
直接嵌入 io/fs.FS 或 os 包类型会导致耦合过重、mock 困难、行为失真。正确做法是定义最小契约接口，把“写入能力”作为一级公民。
立即学习“go语言免费学习笔记（深入）”；
- 接口应含
WriteFile(ctx, path, data, perm)、Delete、Exists、Stat等明确写语义的方法 - 内存实现可用
sync.Map存path → []byte，但WriteFile("a/b/c.txt")需手动解析并创建a/和a/b/目录（memfs已帮你做了） - 若需并发安全，
memfs内部用sync.RWMutex，但目录创建和文件写入仍非原子 —— 如需强一致性，得加额外锁 - 避免在接口里暴露
os.File或fs.File，它们绑定系统调用，无法跨环境替换
真正麻烦的不是“怎么写”，而是“怎么让业务代码不感知底层是磁盘还是内存”。一旦用了 os.OpenFile 或 os.Stat，就等于锁死了实现，再换内存 FS 只能重写逻辑。接口设计时漏掉 ctx 或错误包装，后续加超时或链路追踪就只能动手术。
