服务端HTML模板（如Go的html/template）首屏更快，因浏览器直接解析完整HTML，无需等待JS下载执行，利于FCP/LCP和SEO；JS模板引擎（如mustache.js）仅在局部更新时有优势，整页渲染反损性能——关键在“哪段模板该在哪边渲染”。
服务端 HTML 模板（如 Go 的 html/template、Java 的 FreeMarker）和客户端 JS 模板引擎（如 mustache.js、handlebars）不是“快慢之争”，而是“在哪快、为谁快”的分工问题——首屏必须快，就用服务端模板；局部频繁更新，才轮到 JS 模板引擎上场。
服务端模板为什么首屏更快
浏览器拿到的是完整 HTML 字符串，无需等待 JS 下载、解析、执行即可开始构建 DOM。这对 FCP（首次内容绘制）和 LCP（最大内容绘制）直接友好。
- SEO 友好：搜索引擎爬虫能直接读取已渲染内容，不依赖 JS 执行
- 无 JS 依赖：弱网或禁用 JS 的环境仍可展示基础页面
- HTTP 缓存粒度更细：静态资源或部分 HTML 片段可单独缓存
- 注意陷阱：
html/template在模板中嵌套多层{{if}} {{range}} {{with}}+ 调用未导出方法，会显著拖慢TTFB；FreeMarker 的内调用date?string等格式化函数，每项都触发一次 JVM 方法调用，高并发下易成瓶颈
JS 模板引擎只在局部更新时才有优势
把 mustache.js 或 handlebars 用来渲染整页 HTML，等于主动放弃服务端流式响应、HTTP 缓存和首字节优势——这时候“快”是假象。
- 真正适合场景：评论区追加、搜索建议下拉、实时通知 badge 更新等小范围 DOM 替换
-
mustache.js是解释型，同一模板重复调用会反复正则解析，比预编译的lodash.template慢 2–3 倍（10k 条数据实测） - 避免在
{{#each}}循环里写{{formatDate date}}这类未缓存函数调用，否则迭代 N 次就执行 N 次 JS 函数 - 模板字符串别每次从
document.querySelector('script[type="text/template"]')动态读取，提前存为变量减少 DOM IO
Go 生态里 html/template 和 quicktemplate/templ 性能差在哪
html/template 是运行时解析，每次渲染都要走词法分析 + AST 构建 + 执行；quicktemplate 和 templ 是编译时生成 Go 代码，运行时零分配、零反射、纯函数调用。
立即学习“前端免费学习笔记（深入）”；
-
quicktemplate：基准测试显示BenchmarkQuickTemplate1耗时约120ns/op，html/template同场景为2501ns/op，快 20 倍以上，且内存分配为0B/op -
templ：平均渲染耗时2.3µsvshtml/template的8.7µs，内存分配192Bvs1.2KB - 代价是开发流程增加编译步骤（
go generate或专用 CLI），且模板变更后需重新生成代码 - 安全边界不同：
html/template自带自动转义，quicktemplate和templ需显式调用html.EscapeString或使用类型安全 API，否则 XSS 风险由开发者承担
最容易被忽略的一点：所谓“JS 模板快”，只在数据变化频繁、DOM 更新范围小时成立；所谓“服务端模板慢”，往往是因为把本该前端处理的交互逻辑硬塞进服务端模板里——模板引擎本身没对错，错的是没划清渲染责任边界。
