Go模板性能瓶颈源于重复解析、反射访问和HTML安全处理不当，应预编译模板、扁平化数据并正确使用template.HTML；自定义函数须在Parse前注册且导出，返回template.HTML才能绕过html/template转义。
Go 模板渲染性能瓶颈几乎从不来自函数本身，而来自重复解析、反射访问和不当的 HTML 安全处理。预编译 + 数据扁平化 + 正确使用 template.HTML 是最直接有效的组合。
模板自定义函数必须在 Parse 前注册，否则无效
很多人写完函数就往模板里写 {{myFunc .}}，结果报错或静默失效——根本原因是没注册，或注册时机错了。
-
template.New("name").Funcs(myFuncs).Parse()✅ 正确：注册早于解析 -
t := template.Must(template.ParseFiles("t.html")); t.Funcs(myFuncs)❌ 无效：解析后 FuncMap 已冻结，调用无效果 - 函数名必须首字母大写（导出），签名参数/返回值类型需模板能识别，如
string、int、time.Time、指针或接口 - 返回
template.HTML才能在html/template中绕过转义；若用text/template，返回string即可，但不能混用
html/template 中输出原始 HTML 必须返回 template.HTML 类型
常见错误是 Markdown 渲染后直接返回 string，结果 <p> 被双重转义成 <p></p>，页面显示为源码而非格式化内容。
- 错误写法：
"md": func(s string) string { return markdown.Render(s) }→ 输出被 HTML 转义 - 正确写法：
"md": func(s string) template.HTML { return template.HTML(markdown.Render(s)) }→ 绕过转义 - 注意：
text/template不提供template.HTML类型，也不做自动转义，适合生成邮件、配置等非 HTML 场景 - 把
html/template解析的模板传给text/template.Execute会 panic，反之亦然
避免每次请求都 ParseFiles 或 ParseGlob
这是最常被忽视的性能杀手。一次 ParseGlob 平均耗时 1–5ms（含磁盘 I/O 和 AST 构建），QPS 1000 就意味着每秒白耗 1–5 秒 CPU。
立即学习“go语言免费学习笔记（深入）”；
- 启动时一次性加载：
var tpl = template.Must(template.ParseGlob("templates/**/*.html")) - 子模板用
tpl.Lookup("post.html")获取，不要在 handler 里重新ParseFiles - 修改模板文件后需重启进程；开发期可用
fsnotify监听重载，但生产环境禁用 - 若需差异化 FuncMap（如不同租户不同过滤器），应预先构建多个命名模板：
tpl.Funcs(funcMapA).Lookup("base")，而非运行时切换
减少模板内反射开销：字段访问、range 嵌套、函数调用
html/template 执行时大量依赖反射——每次 .Title、.Posts.0.Name 或 {{range .Items}} 都触发字段查找和类型检查，pprof 显示 reflect.Value.call 占比常超 85%。
- 结构体字段多或嵌套深时，提前扁平化数据：
data := struct{ Title, Body string }{p.Title, string(p.Body)}，再传入模板 - 避免三层以上
{{if .A}}{{if .B}}{{if .C}}，改用 Go 层计算布尔标志：CanEdit: user.Role == "admin" || post.AuthorID == user.ID - 慎用
index、slice等泛化函数，它们比直接访问字段慢 3–5 倍 - 自定义函数体内禁止阻塞操作（DB 查询、HTTP 调用），也不要做
json.Marshal或time.Format—— 这些应在传入模板前完成
真正卡住性能的，从来不是你写的那个 formatDate 函数，而是它被调用了 200 次、每次都在反射找字段、每次都在重建执行上下文。预编译和数据前置，比优化函数本身重要一个数量级。
