直接在 c.html 传参时合并全局配置最稳妥，因 funcmap 全局静态、无法访问 context、易污染共享状态；而显式合并结构体数据流清晰、可测试、支持按请求覆盖。
直接在 c.HTML 传参时混入全局配置是最简单、最可控的方式，不建议用模板函数或中间件“自动注入”，容易污染上下文、掩盖数据来源。
为什么别用 template.FuncMap 注入全局配置
虽然 Gin 支持通过 html/template 的 FuncMap 注册函数（比如 {{ siteName }}），但这类函数无法访问 gin.Context，也就拿不到运行时动态值（如当前用户权限、请求 Host、灰度标记等）。硬编码进 FuncMap 的配置会变成静态常量，改一次要重启服务，且所有模板共享同一份 map，不同路由间无法差异化。
常见错误现象：siteConfig 在测试环境显示正确，上线后始终是开发时的默认值；或者多个子系统共用一个模板目录，结果 A 系统的 cdnHost 覆盖了 B 系统的。
- FuncMap 是全局注册、进程级单例，无法按请求隔离
- 无法结合中间件做条件注入（比如仅对 /admin/* 路由注入管理后台配置）
- 调试困难：模板里看到
{{ .Site.Title }}却不知道它来自哪一层逻辑
c.HTML 传参时合并全局配置最稳妥
把全局配置定义成结构体或 map，在每次调用 c.HTML 前显式合并。这样数据流清晰、可测试、可复用。
示例：
type SiteConfig struct {
Name string
CDN string
Version string
IsProd bool
}
<p>var globalSiteConfig = SiteConfig{
Name: "MyApp",
CDN: "<a href="https://www.php.cn/link/ca904c1dfe5c1e4415ce964959278c45">https://www.php.cn/link/ca904c1dfe5c1e4415ce964959278c45</a>",
Version: "v2.3.1",
IsProd: os.Getenv("GIN_MODE") == "release",
}</p><p>r.GET("/dashboard", func(c <em>gin.Context) {
data := gin.H{
"Title": "Dashboard",
"User": c.MustGet("user").(</em>User),
// 显式合并，优先级：局部 > 全局
"Site": globalSiteConfig,
}
c.HTML(http.StatusOK, "dashboard.html", data)
})
</p>
- 结构体字段名即模板中
{{ .Site.Name }}的路径，语义明确 - 可在 handler 内覆盖字段，比如
"Site": SiteConfig{...}.WithCDN(c.Request.Host) - 单元测试时可直接构造
datamap，无需启动 Gin 引擎
如果真要“自动”注入，用中间件 + c.Set() + 统一渲染封装
当项目模板超过 20 个、且 90% 页面都需相同配置时，可封装一个 renderHTML 函数替代原生 c.HTML，避免重复写 "Site": globalSiteConfig。
关键点：
- 中间件里调用
c.Set("siteConfig", globalSiteConfig)，不是c.Set("Site", ...)—— 避免和业务数据 key 冲突 - 自定义函数只在需要的地方调用：
renderHTML(c, "index.html", gin.H{"Page": "home"}) - 该函数内部统一取
c.MustGet("siteConfig")并 merge 到传入的data中
注意：不要在中间件里直接调用 c.HTML，否则会提前结束响应周期，后续 handler 无法再写 body。
真正难的不是“怎么注入”，而是决定哪些算“全局”—— CDN 地址可能随环境变，站点名称可能随语言变，用户权限状态根本不算全局。把变化频率不同的配置混在一起注入，后期维护成本会指数上升。
