fstest.mapfs只能测只读逻辑，不能写入，调用create、removeall或openfile会panic或返回“operation not supported”；其唯一用途是验证http.fileserver、template.parsefs等只读消费路径是否兼容fs.fs接口。
fstest.MapFS 只能测只读逻辑，别用它写文件
它根本没实现 Create、RemoveAll 或 OpenFile，任何试图写入的操作都会 panic 或返回 "operation not supported"。典型错误是：fs.Create("/x.txt") 直接崩溃，或 os.OpenFile("x.txt", os.O_CREATE, 0644) 返回 *os.PathError。
它唯一靠谱的用途是验证只读路径是否兼容 fs.FS 接口：比如 http.FileServer(http.FS(fs)) 能否响应 GET 请求，template.ParseFS 是否能加载嵌入模板。构造时注意两点：
- 目录键名必须带尾部
/，例如"static/"，否则http.FileServer无法识别为目录 - 目录项的
Mode必须包含fs.ModeDir，否则fs.ReadDir会跳过它
fstest.NewMemMapFS 是标准库里唯一可写的内存 FS
它实现了 fs.ReadWriteFS，支持 Create、Open、ReadFile、WriteFile、RemoveAll 等完整操作，但行为有明显限制：
-
ModTime()默认返回零时间，若业务逻辑依赖时间戳（如日志轮转判断），需手动 patchMapFile.ModTime_ - 不兼容
os.OpenFile—— 它返回的是fs.File，不是*os.File；必须改用fs.Open或fs.ReadFile -
os.Stat、os.Chmod这类函数无法作用于它，得用fs.Stat配合其返回的fs.FileInfo - 自动创建中间目录（类似
mkdir -p），但路径不自动filepath.Clean()，fs.Create("a/../b.txt")就真建出a/../b.txt
需要真实时间戳或细粒度权限？用 memfs 库
github.com/kevin-cantwell/memfs 行为更贴近真实 OS 文件系统：
- 返回的
memfs.File满足io.ReadWriteSeeker和io.Closer，支持Seek和Truncate -
Stat()返回的os.FileInfo包含真实ModTime()和完整Mode位（包括os.ModeSymlink） - 支持
Create、MkdirAll、Chmod、RemoveAll，且调用后必须显式.Close()，否则后续Open可能失败 - 不支持
fs.SubFS，但可用fs.Sub手动包装子路径
但它不处理硬链接、用户/组 ID，若代码调用 os.Lstat 或解析 os.FileInfo.Sys()，仍需 mock Sys() 返回值。
真正解耦文件操作，别硬套标准库接口
io/fs.FS 是只读契约，os 包不可 mock，强行塞进业务逻辑只会让测试越来越脆弱。正确做法是定义最小行为接口：
- 方法全部带
context.Context，由调用方控制超时 - 返回自定义
FileStat结构体，而非fs.FileInfo（避免 S3 实现伪造os.FileInfo） - 错误统一归一：用
ErrNotFound、ErrPermissionDenied等领域错误，不暴露底层os.PathError - 路径标准化必须一致：内存实现和磁盘实现都走
filepath.Clean，否则测试通过、线上报错
最容易被忽略的是：很多测试用 fstest.MapFS 开头，跑着跑着发现要写配置就卡住——它从设计上就拒绝写入，不是 bug，是定位错误。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
