Go 的 html/template 不支持全局变量，所有数据必须显式传入；{{.}} 是传入的 data 本身，{{$.}} 指最外层 data，不存在预定义的 _ 变量；应通过结构体组织数据、FuncMap 注入函数实现复用。
很多刚接触 Go 模板的朋友，尤其是从其他语言转过来的，常常会卡在一个点上：为什么我写 {{._}} 或者 {{$.}} 想访问个“全局”数据，要么报错，要么没反应？
核心问题在于，Go 的 html/template 压根就没有“全局变量”这个概念。 这跟 Ja vaScript 里的 window 或者一些其他模板引擎预设的上下文完全不同。所谓的“用 _”，其实是个常见的误解，根源是把 Go 模板的语法和其他引擎（比如 Handlebars、EJS）的用法搞混了。
为什么 html/template 里写 {{._}} 或 {{$.}} 会报错或没效果
道理很简单：Go 模板的设计哲学就是“显式优于隐式”。模板里能访问的所有数据，都来自于你在执行 Execute 方法时，亲手传进去的那个 data 参数。这个参数就是模板世界的全部，{{.}} 这个点号，指代的就是这个传入值本身。
至于 {{$.}}，它确实存在，但作用是在嵌套的 {{with}} 或 {{range}} 块里，帮你指回最外层的那个 data，而不是什么神秘的全局仓库。最关键的是，Go 模板根本没有预定义一个叫 _ 的变量。
- 如果你在别人的代码里看到用了
_，别慌，那大概率是他们自己把数据包装成了类似map[string]interface{}{"_": xxx}的结构，然后在模板里通过{{._.User.Name}}这样的路径来访问。这完全是自定义的，不是语言特性。 - 如果你直接在自己的模板里写
{{._}}，等着你的多半是类似template: cannot evaluate field _ in type ...这样的错误提示。 - 另外，
html/template为了安全，默认会进行上下文感知的转义，并且禁止访问任意字段。那些未导出的结构体字段（小写字母开头的），在模板里根本就是不可见的。
想让多个模板共享配置或工具函数，该怎么做
既然没有“全局变量”，那团队协作或者项目大了，想共享一些站点配置、工具函数怎么办？答案是：靠结构化的数据和预注册的函数，而不是去幻想一个全局作用域。
真正高效的做法，是统一规划数据结构，并通过 FuncMap 来注入公共函数。
- 注入函数用
FuncMap：把常用的工具函数，比如时间格式化、字符串处理等，通过template.FuncMap注册进去。注册后，在模板里就能像{{now}}、{{formatDate .CreatedAt}}这样直接调用，非常方便。 - 复用数据靠结构体：把那些需要跨模板使用的数据，比如网站名称、CDN基础地址、用户信息等，设计到一个顶层的结构体里。例如：
type PageData struct { SiteName string; User *User; Content interface{} }。每次渲染时，都填充这个结构体实例并传入。 - 避免滥用
map[string]interface{}：虽然用 map 当顶层数据很灵活，但代价是类型不安全、IDE没有代码提示、容易拼错键名。对于长期维护的项目，这不是个好选择。 - 动态字段的优雅方案：如果确实有些数据是动态的、不确定的，可以考虑使用嵌套结构体。比如，定义一个包含所有公共字段的
BaseData结构体，然后让页面专用的数据结构嵌入它。这样，各个处理函数只需要设置自己那部分数据，公共部分自动就有了。
template.ParseFiles 和 template.New 配合 FuncMap 的典型写法
理论说完了，来看一个生产环境中比较稳健的初始化示例。这种方式兼顾了可读性、复用性和类型安全。
立即学习“go语言免费学习笔记（深入）”；
func NewTemplate() (*template.Template, error) {
t := template.New("base").Funcs(template.FuncMap{
"formatDate": func(t time.Time) string {
return t.Format("2006-01-02")
},
"add": func(a, b int) int { return a + b },
})
return t.ParseGlob("templates/*.html")
}
- 顺序很重要：一定要先调用
.Funcs()注册函数，然后再调用.ParseGlob()或.ParseFiles()来解析模板。否则，后面解析的模板是获取不到这些函数定义的。 - 函数自动共享：通过
{{template "header" .}}引入的子模板，会天然继承父模板的FuncMap，不需要重复注册，这点很省心。 - 性能提醒：切忌在每次处理请求、执行
Execute前都去重新解析模板。解析模板是有开销的，而且并发解析可能不安全。标准的做法是在程序初始化时解析好，然后复用那个*template.Template实例。
说到底，掌握 Go 模板的难点，往往不在于 {{.User.Name}} 这种基础语法怎么写，而在于前期如何设计你的数据结构：要不要为未来的扩展预留字段？工具函数是否需要传入 context？业务错误是否应该传递到模板层进行渲染？这些架构层面的决定，远比单个语法点的对错影响更为深远。
