fs.fs仅定义open方法，不提供readdir等能力，需组合其他接口；正确做法是定义含readfile/writefile/delete/exists的storage接口以解耦不同存储后端。
fs.FS不是“文件系统”，只是一个Open函数抽象
很多人一看到fs.FS就默认它是“虚拟文件系统”，结果在写测试时发现fs.ReadDir panic、http.FileServer 返回404，甚至embed.FS能用而自己写的却不行——根本原因在于：fs.FS接口只强制定义了一个方法：Open(name string) (fs.File, error)。它不提供目录遍历、Stat、ReadFile等能力，这些全靠额外接口组合。
这意味着：
- 只实现
fs.FS→fs.ReadDir直接panic：“fs: ReadDir not implemented” -
http.FileServer(http.FS(yourFS))报404 → 很可能Open返回了nil或fs.File.Stat()没正确实现（比如返回nil而非fs.ErrNotExist） -
embed.FS可用 → 是因为它同时实现了fs.ReadDirFS、fs.ReadFileFS、fs.StatFS等多个接口
fstest.MapFS适合只读测试，但目录必须显式声明
fstest.MapFS是标准库最轻量的内存FS，构造简单、无副作用，但极易因路径配置错导致fs.ErrNotExist——它不自动推导目录结构，所有父目录都得手动注册为ModeDir。
常见错误写法：
fsys := fstest.MapFS{
"a/b/c.txt": &fstest.MapFile{Data: []byte("ok")},
}
// ❌ fs.ReadDir(fsys, "a") 会失败：因为"a/"没定义，不是目录
正确做法：
- 路径键名必须带结尾
/表示目录，例如"a/"、"templates/" -
Mode字段要包含fs.ModeDir，如0555 | fs.ModeDir - 目录权限不影响读取，但缺失会导致
fs.ReadDir找不到入口
memfs比fstest.MapFS更接近os.File，但需手动管理生命周期
如果测试逻辑依赖*os.File行为（比如调用file.Seek()、file.Readdir()，或传给日志轮转器），fstest.MapFS和fs.FS抽象层都会失效——这时该用github.com/kevin-cantwell/memfs。
但它不是“即插即用”：
-
memfs.Create()返回的memfs.File必须显式调用.Close()，否则后续Open()可能因“文件被占用”失败 -
fs.Create("a/../b.txt")不会自动clean成b.txt，真实创建a/../b.txt路径，测试中需统一用filepath.Clean()预处理 -
os.Stat、os.Chmod等函数无法作用于memfs实例，必须改用fs.Stat+ 自定义fs.FileInfo实现
别硬套os包，定义自己的Storage接口才是解耦关键
试图用fs.FS或os.File统一S3、本地磁盘、内存FS，注定失败：os.File绑定fd，fs.FS无Write/Delete语义，S3没有“打开句柄”概念。
真正可落地的做法是定义最小契约接口：
ReadFile(ctx context.Context, path string) ([]byte, error)WriteFile(ctx context.Context, path string, data []byte, perm fs.FileMode) errorDelete(ctx context.Context, path string) errorExists(ctx context.Context, path string) (bool, error)
这个接口天然兼容context超时、错误统一映射（如把S3的NoSuchKey转为fs.ErrNotExist），且各实现可自由决定内部机制——本地驱动用os.WriteFile，S3驱动用s3.PutObject，内存驱动用map[string][]byte。路径语义、权限、时间戳等细节，全部由实现自己解释，不强求跨后端一致。
最容易被忽略的一点：所有路径参数不自动trim开头/，也不强制filepath.Clean()——这是留给驱动自己决定是否做路径规范化，而不是在接口层一刀切。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
