能，需用 //go:embed assets/... 声明 embed.FS 类型变量，路径相对于该 Go 文件目录，... 表示递归匹配，读取时必须带前缀如 "assets/config.json"。
go embed 能不能直接嵌入整个目录
能，但必须用 //go:embed 指令配合通配符，且路径必须是**编译时确定的静态路径**。不是写个 os.ReadDir 运行时读就能打包进去——embed 只在构建阶段起作用。
常见错误现象：pattern matches no files，通常是因为路径写错、文件不在模块根目录下，或用了变量拼接路径（embed 不支持动态路径）。
- 路径必须相对于
go:embed所在 Go 文件的目录（不是go.mod目录） - 通配符只支持
*和...：assets/*匹配一级子文件，assets/...才递归匹配所有嵌套文件 - 不能嵌入空目录；如果目录下没文件，
embed.FS里对应路径就不存在
怎么声明一个嵌入整个 assets 目录的 FS 变量
声明方式很固定，关键在类型和注释位置：必须是 embed.FS 类型变量，//go:embed 注释紧贴变量声明上方，中间不能有空行。
示例：
立即学习“go语言免费学习笔记（深入）”；
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
//go:embed assets/... var assetsFS embed.FS
注意：assets/... 中的 ... 是 embed 的特殊语法，不是 glob 通配符，它表示“递归包含所有子目录”。写成 assets/** 或 assets/*/* 都无效。
- 变量名可以任意，但类型必须是
embed.FS（不是*embed.FS或其他） - 如果想嵌多个目录，每个都要独立声明，不能在一个注释里写多个路径
- 路径区分大小写，Windows 下容易因大小写不敏感掩盖问题，Linux/macOS 构建会直接失败
读取嵌入文件时为什么提示 "file does not exist"
不是文件真丢了，而是 embed.FS 的路径规则和本地文件系统不一致：它以声明时的路径为根，且**不自动补前导 /**。
比如你声明了 //go:embed assets/...，那所有文件路径都以 assets/ 开头，必须显式带上这个前缀才能读到：
content, err := assetsFS.ReadFile("assets/config.json") // ✅ 正确
content, err := assetsFS.ReadFile("config.json") // ❌ 报错：file does not exist
-
embed.FS的路径是“虚拟文件系统”，没有相对路径解析逻辑，..和.都不支持 -
ReadDir返回的fs.DirEntry名称不含父路径，但FS.Open仍需完整路径 - 调试建议：用
fs.WalkDir(assetsFS, ".", ...)打印所有嵌入路径，确认实际结构
嵌入大目录时要注意哪些性能和兼容性问题
嵌入本身不耗运行时资源，但会影响二进制体积和构建速度——所有文件内容在编译期转成 Go 字节码，硬编码进二进制。
- 10MB 的静态资源会让二进制增大约 10MB（base64 编码后略多），启动时间不受影响，但加载
embed.FS变量本身是零开销 - Go 1.16+ 支持，低于此版本无法编译；交叉编译时，嵌入内容与目标平台无关，无需额外处理
- 避免嵌入日志文件、临时生成文件等非静态内容——它们不会被更新，除非重新构建
- 如果目录含大量小文件（如前端 chunk），嵌入后
FS.ReadFile性能优于磁盘 I/O，但首次WalkDir会有轻微延迟（需遍历内部索引）
最常被忽略的一点：嵌入路径里的符号链接会被跳过，且不报错；如果你依赖软链组织资源，得先用 cp -L 展开再嵌入。
