html/template 默认不缓存解析结果是因为每次调用 Parse 或 ParseFiles 都会重新词法分析和构建语法树，即使模板内容未变；需在初始化阶段显式缓存 *template.Template 实例。
为什么 html/template 默认不缓存解析结果？
Go 标准库的 html/template 在每次调用 Parse 或 ParseFiles 时都会重新词法分析和语法树构建，即使模板内容完全没变。这意味着高频请求下反复解析同一组模板会浪费 CPU 和内存。
解决方法是显式缓存已解析的 *template.Template 实例，而不是每次请求都重解析：
- 在应用初始化阶段（如
init()或main()开头）一次性调用template.ParseFiles或template.New(...).Parse(...) - 将返回的
*template.Template存为包级变量或注入到 handler 结构体中 - 避免在 HTTP handler 内部调用
Parse—— 这是最常见的性能陷阱
示例错误写法：
func handler(w http.ResponseWriter, r *http.Request) {
t := template.Must(template.ParseFiles("index.html")) // ❌ 每次请求都解析
t.Execute(w, data)
}
如何安全地复用模板并支持子模板热更新？
生产环境需要兼顾性能与可维护性：模板不能每次改完就重启服务，但也不能放弃缓存。标准库本身不提供热重载，需手动控制生命周期。
推荐做法是封装一个带条件重载能力的模板管理器：
立即学习“go语言免费学习笔记（深入）”；
- 使用
sync.RWMutex保护模板实例读写 - 通过文件修改时间（
os.Stat().ModTime()）判断是否需要重新解析 - 仅在检测到变更时调用
Clone()+ParseFiles()，避免锁住整个渲染流程 - 注意：不要直接调用
template.ParseGlob后反复Execute—— 它不自动处理嵌套{{define}}的依赖关系
关键点：子模板（如 {{template "header" .}}）必须和主模板一起被 ParseFiles 加载，否则运行时报错 template: "header" is undefined。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
为什么 text/template 渲染比 html/template 快，但不能随便换？
两者底层共享大部分逻辑，但 html/template 多了一层自动转义（HTML escaping），会对每个 .Field 调用 HTMLEscapeString。这带来约 10%–20% 的额外开销。
只有在确认数据**完全可信且不含用户输入**时，才考虑切换：
- 纯静态页面生成（如文档站点、内部报表）
- 所有输出字段都来自硬编码或配置文件，未经过任何表单提交或 URL 参数注入
- 切记：一旦混入
r.URL.Query().Get("q")这类值，就必须用html/template防 XSS
替换方式很简单：
t := texttemplate.Must(texttemplate.ParseFiles("page.txt")) // 注意 import 是 "text/template"但文件扩展名和内容语义不变，仍可写 {{.Title}}。
HTTP 层还能做哪些轻量但有效的优化？
模板只是渲染一环，前端性能还卡在传输和客户端解析上。几个低成本高回报的操作：
- 启用 Gzip 压缩：用
gziphandler.GzipHandler（第三方库）或自定义ResponseWriter包装器，对text/html响应压缩，通常减少 60%+ 体积 - 设置
Content-Type显式带charset=utf-8，避免浏览器触发字符集探测延迟渲染 - 添加
Cache-Control: no-cache或更精细的策略（如public, max-age=300），防止重复请求相同 HTML - 避免在模板里写内联 JS/CSS 超过 1KB —— 不利于浏览器缓存复用，也拖慢首字节时间（TTFB）
真正卡顿的往往不是 Go 渲染速度，而是模板里调用了未加缓存的数据库查询、或嵌套了多次 http.Get。这些必须从逻辑层剥离，而不是指望模板优化能救场。
