如何利用HTML模板打造面向未来的组件化架构

<template>是原生组件化的最小基础设施，非完整架构；它不执行脚本、不加载资源，须配合document.importNode(tmpl.content, true)克隆以保留状态并兼容Shadow DOM。

纯 HTML 的 <template> 标签本身不构成“面向未来的组件化架构”，它只是原生组件化的最小基础设施——真正决定架构是否可持续的，是围绕它建立的数据映射逻辑、样式隔离策略和复用契约。

为什么<template>不能直接替代 Web Components

浏览器跳过 <template> 内容解析，它既不执行 <script>，也不加载图片或应用 CSS。常见误操作是把模板当 Vue 组件写，结果 DOM 里空空如也。更关键的是：cloneNode(true) 会丢失 <input checked> 状态，而 innerHTML = tmpl.innerHTML 会破坏表单控件的初始值；document.importNode(tmpl.content, true) 才是唯一能保留状态、兼容 Shadow DOM 的克隆方式。

如何让<template>支持安全数据填充

纯 HTML 不识别 {{title}} 这类插值语法，必须由 JS 显式替换。但直接 node.textContent = data.title 或 node.innerHTML = data.content 有 XSS 风险，尤其后者。

• 只对明确信任的字段（如配置项、枚举值）用 textContent
• 对富文本内容，先用 DOMPurify.sanitize() 过滤，再塞进 innerHTML
• 避免在模板内硬编码 ID（如 id="card-1"），多次实例化会导致重复 ID，影响 querySelector 和 CSS 选择器
• 绑定点统一用 data-bind="title"，不用 class 名，否则改样式时易误删绑定逻辑

何时该放弃<template>转向 Custom Elements

当出现以下任一情况，说明 <template> + 手动 JS 已到边界：

立即学习“前端免费学习笔记（深入）”；

• 需要响应属性变更（比如 <user-card loading> 切换状态）——attributeChangedCallback 只在 Custom Element 中生效
• 多个页面共用同一组件，且需独立样式作用域——<template> 无法阻止全局 CSS 泄漏，Shadow DOM 是刚需
• 组件内要监听点击、输入等事件，又不想污染全局 document ——Custom Element 的 this.shadowRoot.addEventListener() 提供天然作用域
• 需要 SSR 支持或 hydration 行为——<template> 是纯客户端方案，服务端无法预渲染

真正面向未来的架构，不是选 <template> 还是 Custom Elements，而是清楚每种技术的不可替代性：用 <template> 做轻量级、低频、静态内容复用；用 Custom Elements 封装带状态、需交互、跨环境一致的 UI 单元。混淆二者边界，才是最常被忽略的复杂点。