text/template渲染变慢主因是重复解析模板、未复用*template.Template实例、循环中频繁Execute；应初始化时解析并全局复用，避免运行时ParseFiles、模板内计算及反射遍历。
为什么 text/template 渲染变慢？常见瓶颈在哪
模板渲染变慢通常不是因为语法复杂，而是源于重复解析、未复用 *template.Template 实例、或在循环中频繁调用 Execute。尤其当模板从文件读取且未预编译时，每次请求都触发 ParseFiles 或 ParseGlob，会反复 lex → parse → build AST，开销显著。
真实场景中，以下操作极易成为性能拖累：
- 每次 HTTP 请求都调用
template.New("name").ParseFiles(...) - 模板内使用
{{template "sub" .}}但子模板未提前定义（导致运行时查找失败+panic 或 fallback 重解析） - 传入的数据结构含大量未导出字段或嵌套 map[string]interface{}，反射深度遍历耗时陡增
必须复用已解析的 *template.Template 实例
模板解析是 CPU 密集型操作，而执行（Execute）是轻量级的。正确做法是在程序初始化阶段完成解析，并全局复用。
错误写法：
立即学习“go语言免费学习笔记（深入）”；
func handler(w http.ResponseWriter, r *http.Request) {
t, _ := template.ParseFiles("index.html")
t.Execute(w, data)
}
正确写法（推荐在 init() 或 main() 中完成）：
var indexTmpl = template.Must(template.ParseFiles("index.html"))
func handler(w http.ResponseWriter, r *http.Request) {
indexTmpl.Execute(w, data)
}
若需动态加载更新模板（如开发环境热重载），应单独封装 reload 逻辑，避免影响主请求路径；生产环境禁止运行时解析。
用 template.Must 捕获解析期错误，别留到运行时
template.Parse* 系列函数返回 (*Template, error)，忽略 error 会导致后续 Execute panic（如 template: xxx: "yyy" is not defined）。这类错误本应在启动时暴露，而非等到用户访问才崩。
务必使用 template.Must 强制提前失败：
var userTmpl = template.Must(
template.New("user").
Funcs(template.FuncMap{"upper": strings.ToUpper}).
ParseFiles("user.html", "layout.html"),
)
注意：Must 在 error != nil 时直接 panic，适合初始化阶段；不要在请求处理中调用它。
避免在模板中做计算，把逻辑前置到 Go 代码中
text/template 不支持函数重载、无类型推导、无缓存表达式结果。像 {{len .Items}}、{{.User.CreatedAt.Format "2006-01-02"}} 这类调用，每次渲染都重新反射取值 + 执行方法，比在 Go 层预计算慢数倍。
优化建议：
- 将格式化结果作为字段注入数据结构：
ViewData{DateStr: u.CreatedAt.Format("2006-01-02")} - 用
range前预先过滤/截断切片，而非在模板里写{{if lt $i 10}} - 复杂条件判断（如权限检查）统一收口到
FuncMap，并确保函数本身无副作用、不依赖外部状态
一个典型反例：{{if eq .Status "active"}}...{{else if eq .Status "pending"}}... —— 若 .Status 是字符串常量，直接传 IsActive 布尔字段更高效。
真正影响性能的从来不是模板语法本身，而是你让模板承担了不该它做的事：数据转换、业务判断、IO 调用。把计算移出去，把模板当成纯展示层，效率提升立竿见影。另外，html/template 因自动转义额外消耗约 15% 时间，如确定内容安全，可考虑用 text/template 替代，但需自行保障 XSS 防御。
