fstest.MapFS不能当真实内存文件系统用，因其仅为单元测试设计的只读抽象，不支持写操作、无目录结构、路径处理脆弱且fs.File不可重复读；应定义带context和自定义错误的FileStore接口，用树形Node结构配合细粒度锁实现安全读写删。
Go 语言里想快速搭个能读写删的内存文件系统，别用 fstest.MapFS —— 它只读，一调 WriteFile 就 panic，根本不是为“存数据”设计的。
为什么 fstest.MapFS 不能当真实内存文件系统用
fstest.MapFS 是标准库专为单元测试静态资源准备的只读抽象。它实现的是 io/fs.FS 接口，但所有写操作（os.Create、os.WriteFile、os.MkdirAll）都会直接 panic；fs.Open 返回的 fs.File 不支持重复读取；路径必须是字面量，"./a/b" 这种带 . 或 .. 的写法会失败；fs.WalkDir 遍历出来的 DirEntry.IsDir() 永远返回 false —— 因为它压根没目录结构概念。
换句话说：它适合测模板渲染、打包嵌入资源，不适合做“用户能增删改查”的内存盘。
自己定义 FileStore 接口才真正可控
要支持创建、写入、删除、存在性检查，必须脱离 io/fs.FS，定义自己的接口。比如：
立即学习“go语言免费学习笔记（深入）”；
type FileStore interface {
ReadFile(ctx context.Context, path string) ([]byte, error)
WriteFile(ctx context.Context, path string, data []byte, perm fs.FileMode) error
Delete(ctx context.Context, path string) error
Exists(ctx context.Context, path string) (bool, error)
Stat(ctx context.Context, path string) (FileStat, error)
}
-
path必须先过filepath.Clean()，否则"a/../b"在内存实现里变成"b"，而磁盘上可能还是"a/../b"，导致测试通过、线上出错 -
WriteFile("/a/b/c.txt", ...)要自动递归创建/a和/a/b目录，不能假设父目录一定存在 - 并发安全必须靠
sync.RWMutex或sync.Map，但sync.Map不适合存嵌套树状结构，建议用带锁的map[string]*Node
Node 树结构比 map[string][]byte 更实用
用扁平 map[string][]byte 存文件内容，看似简单，但无法表达目录层级、无法支持 ls /a 这类列出子项操作。真实项目中推荐树形 Node：
type Node struct {
name string
content string // 非空表示是文件
children map[string]*Node // 非空表示是目录
}
- 新建
/x/y/z.txt时，需逐级检查并创建/x→/x/y节点 -
ls("/x")就是遍历node.children的 key 列表 - 重命名
/x/a.txt→/y/b.txt，本质是：从/x的 children 删除a.txt，再往/y的 children 插入b.txt—— 必须同时锁定两个父节点，否则并发下可能丢文件
路径解析和锁粒度是高频踩坑点
很多初学者在 SplitPath("/a/b/c") 时直接用 strings.Split(path, "/")，结果 "" 开头、结尾空串处理错，导致根节点访问异常；还有人对整个文件系统只用一把全局锁，性能差且容易死锁。
更稳妥的做法：
- 用
filepath.Clean()统一标准化路径，再用strings.TrimPrefix(filepath.Clean(path), "/")去掉开头斜杠 - 按路径前缀分段加锁：操作
/a/b/c时，锁住/a和/a/b两级父节点即可，不必锁全树 - 读操作用
RWMutex.RLock()，写操作用Lock()，避免读多时阻塞
真正的难点不在“怎么存”，而在“怎么让多 goroutine 安全地一起操作同一棵树”——锁的范围、时机、顺序，稍有不慎就会出现文件丢失或 panic。
