服务端HTML模板和前端模板引擎均不支持运行时组件化，仅提供编译期抽象或字符串拼接；真正实现组件化渲染的是React/Vue等前端框架，具备响应式更新与增量DOM操作能力。
服务端 HTML 模板（如 html/template、Templ、quicktemplate）不支持运行时组件化
HTML 模板引擎在服务端执行，渲染结果是静态 HTML 字符串。它没有 DOM、没有事件循环、没有响应式系统，所谓“组件”只是函数调用或模板继承的编译期抽象。比如 html/template 的 {{template "header" .}} 是文本替换，Templ 的 Header() 函数是编译后直接拼接字符串——它们都不产生可复用、可挂载、可更新的运行时组件实例。
常见误解：以为用 {{define}} 或 partial 就算组件化。实际这些只是服务端的代码组织方式，和前端框架的组件生命周期、props 传递、状态同步毫无关系。
- 无法响应数据变更重新渲染某一块（除非整页重刷或手动 AJAX + innerHTML 替换）
- 不隔离样式作用域（CSS 全局污染，需靠 BEM 或 CSS-in-JS 模拟）
- 无客户端交互能力——按钮点击后不能局部更新评论数，得发请求、收 JSON、再 JS 拼 DOM
前端模板引擎（如 mustache.js、handlebars）的“组件”本质是字符串拼接函数
像 mustache.js 这类纯字符串模板引擎，Mustache.render(template, data) 返回的永远是一段 HTML 字符串。它不创建组件实例，也不管理 DOM 生命周期；所谓“复用”，只是多次调用同一个 render 函数传不同数据。
性能关键点不在“是否组件”，而在“是否预编译”和“是否避免重复解析”：
立即学习“前端免费学习笔记（深入）”；
-
mustache.js每次调用都正则解析模板，10k 条数据下比lodash.template慢 2–3 倍 -
Handlebars.compile()只需一次编译，后续template(data)是纯函数执行，适合列表高频刷新 - 模板内调用未缓存函数（如
{{formatDate date}}）会导致每次迭代都执行 JS，应提前格式化好字段
真正支持组件化渲染的是前端框架（React/Vue），不是前端模板引擎
前端模板引擎 ≠ 前端框架。写 {{#each items}}{{name}}{{/each}} 不等于有虚拟 DOM、diff、reconciliation。只有 React 的 useState + map 或 Vue 的 v-for + 响应式依赖追踪，才能实现：数据变 → 组件重渲染 → 增量 DOM 更新。
拿一个商品列表对比：
- 用
handlebars渲染：数据变 → 调template(newData)→ 得新 HTML 字符串 →el.innerHTML = ...→ 全量重绘整个列表 DOM - 用 React 渲染：数据变 → 触发 re-render → diff 对比 → 只更新价格节点的
textContent，其余 DOM 复用
后者在长列表滚动、实时库存变化等场景下，帧率更稳、内存更省、用户感知更顺滑。
混合方案才是现代应用的性能平衡点
首屏内容用服务端 HTML 模板（如 quicktemplate）直出，保证 LCP 快、CLS 稳、SEO 友好；登录态、购物车角标、评论区等动态区块，用前端框架组件加载并接管。
最容易被忽略的性能陷阱是：把本该服务端渲染的静态结构（比如页头、导航栏）硬塞进前端模板引擎里渲染。这既丢了服务端流式传输优势，又让客户端多干了本可避免的字符串拼接和 innerHTML 写入——尤其在低端安卓机上，单次 innerHTML 写入 50KB HTML 就可能卡顿 30ms 以上。
