必须用 template.ParseFS 手动加载 embed.FS：因 LoadHTMLGlob 仅支持文件路径字符串，不接受 fs.FS 接口；需 //go:embed 声明、ParseFS 解析、r.SetHTMLTemplate 注入，并确保 c.HTML 模板名与解析名一致。
嵌入式系统打包 HTML 页面时，不能依赖 LoadHTMLGlob 或文件系统读取，因为目标设备通常无写入权限、无完整文件系统，甚至 Flash 只读。必须用 Go 1.16+ 的 embed 将页面编译进二进制，再通过 html/template 加载——但直接传 embed.FS 给 r.LoadHTMLGlob 会失败，它只认本地路径字符串。
为什么 LoadHTMLGlob 无法直接用 embed.FS
LoadHTMLGlob 内部调用的是 template.ParseGlob，该函数只接受文件路径（string），不接收 fs.FS 接口；它会尝试打开磁盘路径，而嵌入式设备上这些路径根本不存在。你看到的 panic 通常是 open templates/index.tmpl: no such file or directory，哪怕你已正确声明了 //go:embed 注释。
用 template.Must(template.New("").ParseFS(...)) 手动加载
这是唯一可靠的方式：绕过 Gin 的模板加载逻辑，自己构造 *template.Template，再注入到 Gin 的渲染器中。关键点是使用 template.ParseFS（Go 1.16+），它原生支持 fs.FS。
实操步骤如下：
- 在 main 包顶部声明 embed 变量，路径需精确匹配模板所在目录，例如：
//go:embed templates/* var templatesFS embed.FS
- 创建模板对象并解析：
t := template.Must(template.New("").ParseFS(templatesFS, "templates/*.tmpl"))注意通配符必须写在字符串里，且路径前缀（templates/）要和 embed 声明中的路径一致 - 将模板对象设给 Gin 引擎：
r.SetHTMLTemplate(t)
这一步不可省略，否则c.HTML仍会尝试走默认加载逻辑
模板路径与 c.HTML 中的 name 必须完全匹配
c.HTML 第二个参数（模板名）不是文件路径，而是 template.ParseFS 解析后注册的模板名。若你用 "templates/*.tmpl"，Go 会把每个文件名（不含扩展名）作为模板名，比如 templates/index.tmpl → 模板名为 index；若文件在子目录如 templates/admin/dashboard.tmpl，模板名就是 admin/dashboard。
常见错误包括：
- 传
"index.tmpl"给c.HTML→ 报错template: "index.tmpl" is undefined（应传"index"） - embed 路径写成
//go:embed templates，但ParseFS写成"templates/*.tmpl"→ 实际嵌入的是整个templates目录，没问题；但如果写成//go:embed templates/*，再用"*.tmpl"，就会漏掉子目录 - 模板里用了
{{template "header" .}}，但header.tmpl没被 glob 匹配到（比如扩展名是.html）→ 渲染时报template: "header" is undefined
更新页面后必须重新编译二进制
embed 是编译期行为，修改任何 .tmpl 文件后，go build 才会重新打包。没有热重载，也没有运行时 reload 机制。如果你在开发阶段频繁改页面，建议加一个构建脚本，自动检测 templates/ 变更并触发 rebuild；上线后，整个二进制就是最终交付物，版本管理要同步模板变更记录。
最容易被忽略的一点：嵌入式设备上调试模板错误非常困难——ParseFS 失败会 panic，而 gin.Recovery 默认输出堆栈到 stdout，在无终端的 ARM Linux 上可能卡死或静默失败。务必在生产构建中用 gin.RecoveryWithWriter(ioutil.Discard)，并在启动前加日志打印 len(t.Templates()) 确认模板数是否符合预期。
