模板渲染慢主因是未预编译、路径匹配过宽或数据结构低效；须在router.Run()前用LoadHTMLGlob或LoadHTMLFiles一次性加载模板，传struct而非gin.H，并分离静态资源。
模板渲染慢，八成不是 Gin 本身的问题，而是模板加载或数据传递方式没对。Gin 的 HTML 渲染本身开销极低，真正卡点在模板解析阶段——尤其是每次请求都重复解析、路径匹配太宽、或用了未缓存的 LoadHTMLFiles。
模板必须在启动时一次性加载，不能运行时 reload
Gin 的模板引擎基于 Go 标准库 html/template，所有模板需在 router.Run() 前完成解析和编译。若你在中间件或 handler 里反复调用 LoadHTMLGlob，不仅无效（Gin 会忽略后续加载），还会掩盖真实问题。
-
LoadHTMLGlob("templates/**/*")只能调用一次，且必须在路由注册前 - 开发期想热更新？别指望 Gin 自带机制——得靠第三方工具如
air或自己监听文件变化后重建*gin.Engine - 误写成
r.LoadHTMLGlob("templates/*.html"); r.LoadHTMLGlob("templates/admin/*.html")会导致后者覆盖前者，部分模板丢失
避免 glob 模式过度匹配，尤其慎用双星号 **
** 看起来方便，但实际会触发深度递归扫描，模板越多、目录越深，启动耗时越明显。实测 200+ 模板文件下，"templates/**/*" 比 "templates/*.html" 多花 300–500ms 启动时间。
- 只有一级模板？用
LoadHTMLGlob("templates/*.html")或LoadHTMLGlob("templates/*.tmpl") - 真有多级目录（如
templates/admin/,templates/user/）？改用LoadHTMLFiles显式列出关键模板，比如：LoadHTMLFiles("templates/base.html", "templates/admin/dashboard.html", "templates/user/profile.html") - 别把
.gitignore、.DS_Store或备份文件（*~,#*）混进模板目录——**会尝试解析它们，报错或阻塞
渲染时传 struct 而非 map[string]interface{}，减少反射开销
c.HTML(200, "page.html", gin.H{...}) 看起来简洁，但 gin.H 是 map[string]interface{}，模板执行时需大量反射取字段；而结构体是编译期确定的，字段访问快 2–4 倍。
- 定义明确结构体，比如：
type PageData struct { Title string; Items []string; IsAdmin bool } - handler 中直接传实例：
c.HTML(200, "page.html", &PageData{Title: "Home", Items: items}) - 如果字段动态多变（如 CMS 页面），再退回到
gin.H，但要接受这点性能代价 - 切忌在模板里用
{{.User.Data.Info.Name}}这种深层嵌套——每层.都是一次反射查找，扁平化数据结构更稳
静态资源不走模板渲染，别让 HTML 模板干 JS/CSS 的活
有人把 CSS 内联进模板、JS 拼接进 {{.Script}}、甚至 base64 图片塞进 HTML，这会让单次 HTML 调用体积暴涨，网络传输 + 浏览器解析都变慢。
- 静态文件统一用
r.Static("/static", "./static")提供，模板里只写 - 避免在模板中用
{{template "js-inline" .}}注入大段 JS —— 改为外部 script 标签 + data-* 属性传必要参数 - 图片、字体等二进制资源坚决不走模板变量，否则
HTML方法会尝试转义二进制内容，可能 panic 或乱码
真正影响首屏速度的，往往不是「模板语法多复杂」，而是「模板有没有被正确预编译」「数据结构是否利于快速取值」「静态资源是否被错误地揉进 HTML 字符串里」——这些地方一动，QPS 和 TTFB 就有可测量的变化。
