io/fs.FS 是只读抽象，不管理文件句柄生命周期，fs.File 为一次性对象，Close 后再读即 panic；安全读法为 fs.ReadFile 或 io.ReadAll 一次性读完。
为什么 io/fs 不能直接读文件，一用就 panic: "invalid operation on closed file"
因为 io/fs.FS 是只读抽象，它不提供打开写入、也不管理文件句柄生命周期。你拿到的 fs.File 实际是封装了底层资源的一次性对象——调用 Close() 后再读就会崩，但很多人误以为它像 *os.File 那样可反复用。
常见错误现象：fs.ReadFile 没问题，但自己用 f, _ := fsys.Open("x.txt"); defer f.Close(); io.ReadAll(f) 却在第二次读时 panic。
-
fs.File的Read()只能调用一次（除非底层实现支持重放，但标准os.DirFS不支持） - 别对
fs.File做Seek(0, 0)—— 它不保证实现io.Seeker - 真正安全的读法：要么用
fs.ReadFile(fsys, "path")，要么用io.ReadAll一次性读完，别留着f复用
embed.FS 和 os.DirFS 的行为差异在哪
两者都实现了 io/fs.FS，但语义完全不同：一个编译期固化，一个运行时挂载。
-
embed.FS：打包进二进制，路径必须是字面量（//go:embed assets/*），且不支持fs.ReadDir返回真实fs.DirEntry的IsDir()—— 它永远返回false（因为没系统调用支撑） -
os.DirFS("/tmp")：真实目录映射，支持Stat、ReadDir、符号链接解析，但路径是相对/tmp的，比如Open("a/b.txt")查找的是/tmp/a/b.txt - 混用风险：把
embed.FS当成可写 FS 传给需要热重载逻辑的代码，会静默失败
如何让自定义 io/fs.FS 支持 fs.WalkDir 正确遍历
fs.WalkDir 依赖 ReadDir 返回的 fs.DirEntry 是否准确标记目录/文件，而很多手写 FS 实现只填了名字，没设 IsDir() 标志位。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 错误写法：
return fs.FileInfo转成fs.DirEntry时忽略IsDir()，导致WalkDir把目录当文件跳过子树 - 正确做法：实现
ReadDir时，每个fs.DirEntry必须返回真实IsDir()结果；若用fs.Stat获取信息，注意os.FileInfo.IsDir()是可靠来源 - 性能提示：
WalkDir默认深度优先，如果目录极深或文件极多，建议加context.WithTimeout控制，否则可能卡死
替换 os.Open 为 fs.FS 时最容易漏掉的兼容点
不是所有 os 函数都有 fs 对应体，尤其涉及状态变更或系统特性时。
-
os.Getwd()→ 没有等价fs版本，得自己维护“当前工作目录”上下文 -
os.Symlink/os.Readlink→io/fs不暴露符号链接操作，os.DirFS会解析，但embed.FS完全无视 -
os.Chmod/os.Chown→fs.FS是只读契约，强行实现会违反接口语义，调用方可能崩溃或静默忽略 - 路径分隔符：Windows 下
os.DirFS("C:\data")接受"a\b.txt"，但embed.FS只认/，用filepath.ToSlash统一转换再传入
最常被忽略的是：fs.FS 不承诺并发安全，多个 goroutine 同时调用 Open 没问题，但如果你的自定义实现里用了共享 map 且没加锁，就会竞态。
