先说结论：纯 HTML 模板组件本身并不具备所谓的“高性能渲染”能力，真正决定页面流畅度的关键在于你如何用 JavaScript 进行控制——尤其是能否做到避免重复解析、减少 DOM 操作以及实现按需挂载。不少开发者在这方面都曾踩过坑，今天我们就来详细拆解其中的关键要点。
为什么 innerHTML 配合字符串拼接在高频更新时会导致卡顿
很多开发者习惯将模板写成字符串形式，每次数据发生变化就执行 el.innerHTML = template(data)。这种写法虽然简单直接，但浏览器每次都需要走一遍完整流程：重新解析 HTML 字符串 → 构建 DOM 树 → 废弃旧节点 → 触发重排与重绘。特别是当模板中包含 或焦点元素时，输入状态会直接丢失，用户体验瞬间大打折扣。
- 真实场景：表格每秒刷新 10 行数据，如果使用
innerHTML方式，输入框会频繁失焦，滚动条也会随之跳动。 - 根本原因：DOM 替换本质上是全量销毁与重建，而非增量式的 diff 更新机制。
- 替代思路：改用
document.createElement手动创建节点并复用已有元素，或使用template标签配合content.cloneNode(true)来避免重复解析的开销。
使用 appendChild 原始 content
标签确实能够避免运行时的重复解析过程，这一点值得肯定。但其内部的 content 是一个 DocumentFragment，不能多次直接调用 appendChild——因为第二次调用时节点已经被移走，结果要么报错要么毫无效果。
- 错误写法：
el.appendChild(template.content)连续调用两次 → 第二次完全无效。 - 正确做法：每次使用
template.content.cloneNode(true)获取一个全新的副本再进行操作。 - 性能提示：
cloneNode(true)比innerHTML速度更快，但比虚拟 DOM 的 patch 机制要慢一些；它更适合中低频更新的场景，例如列表页和配置面板这类页面。
动态绑定字段时，避免使用 eval 和 with，推荐用函数构造器生成渲染器
如果想让模板支持类似 {{name}} 的插值语法，又不想引入大型框架？千万不要使用 eval（一方面存在安全隐患，另一方面它无法被 JIT 优化），也不要使用 with（严格模式下直接被禁用，且变量查找性能较差）。
- 推荐方式：将模板字符串转换为函数体，使用
new Function('data', 'return `...${data.xxx}...`')结构来构建渲染函数。 - 注意点：必须对
data进行属性访问校验，否则${data.user.name}在user为null时会直接报错；可以使用${data?.user?.name ?? ''}来兜底处理（前提是目标环境支持可选链）。 - 更稳方案：在预编译阶段将
{{user.name}}替换为${data.user && data.user.name || ''}，再生成函数，运行时更加稳定可靠。
最后需要强调一点：真正的性能瓶颈往往不在于模板语法本身，而在于你是否让同一份 DOM 节点反复经历 removeChild 和 appendChild？是否在 scroll 事件中触发了整块区域的重渲染？有没有将静态内容和动态内容混在同一个 innerHTML 赋值里？这些细节问题，比单纯纠结于选择什么模板引擎，影响要大得多。
