<template>标签是惰性DOM片段仓库，必须用document.importNode(tmpl.content, true)安全克隆并填充数据，禁用innerHTML操作以防丢失表单状态、事件和资源加载；需动态重设ID/name/for、避免硬编码ID、配合Shadow DOM实现样式隔离，其本质是JS驱动的模具而非原生组件。
<template> 标签本身不是组件，它只是个“待激活的模具”——不渲染、不执行脚本、不加载资源。想靠它构建模块化架构，核心不在标签本身，而在你如何用 JS 激活、克隆、填充和复用它。
为什么直接 innerHTML = template.innerHTML 会出问题
常见错误是把 <template id="card"><div><input type="checkbox" checked></div></template> 当作可直接插入的 HTML 字符串处理。这么做会丢失表单控件状态（比如 checked 属性不会被保留），<script> 和 <style> 也不会执行或生效，更别说 data-* 绑定逻辑了。
- 用
innerHTML覆盖容器，等于丢弃原有 DOM 节点，所有事件监听、焦点状态、输入值全清零 - 模板内含
<img src="avatar.jpg">？innerHTML不会触发图片加载，但document.importNode()会 - 若模板里写了
{{title}}这类插值，浏览器原生完全无视，必须手动替换
怎样安全克隆并注入数据：用 document.importNode() 替代 cloneNode()
document.importNode(tmpl.content, true) 是唯一能保全表单状态、正确处理 <select> 选项、兼容 Shadow DOM 的克隆方式。它不是语法糖，而是 DOM 规范中为模板内容设计的专用通道。
- 获取模板：
const tmpl = document.getElementById('card-template') - 克隆内容：
const fragment = document.importNode(tmpl.content, true)（第二个参数必须为true） - 查找绑定点：
fragment.querySelectorAll('[data-bind]')，例如data-bind="title"对应标题节点 - 填充文本：
node.textContent = data.title；填充 HTML（慎用）：node.innerHTML = data.content（注意 XSS） - 挂载：
container.appendChild(fragment)，永远别用innerHTML = ...覆盖已有结构
如何让 template 组件支持“传参”和复用
纯 <template> 没有属性、生命周期或响应式机制。“传参”本质就是调用 JS 工厂函数时传入一个对象，再由代码映射到 DOM 节点。它适合静态内容或低频交互场景，不适合高频更新。
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
立即学习“前端免费学习笔记（深入）”；
- 模板内禁用硬编码 ID，如
id="card-1"—— 多次调用会导致重复 ID，破坏 CSS 查询和 JS 选择器 - 用语义化
data-bind属性，比如data-bind="author-name"，比class="author"更易维护、不易冲突 - 工厂函数应返回
DocumentFragment或真实 DOM 节点，而非字符串，避免每次调用都重新解析 HTML - 如需局部更新，缓存首次生成的节点，后续只改
textContent或dataset值，不重新克隆整个模板
template 方案的硬边界：样式泄漏与封装缺失
它不提供封装性，也不隔离样式。一个 .card__title 类名写在全局 CSS 里，就可能被其他模块意外覆盖；反过来，外部样式也容易穿透进来。这不是 bug，是设计使然。
- 若用
<template>配合普通 DOM 插入，必须靠 BEM 命名 + 构建时自动加前缀（如card-v2__title）来防泄漏 - 若想真正隔离样式，得配合
Shadow DOM或contentDocument，但这会带来新约束：比如:focus-visible等伪类默认不透出 - Web Components 提供封装，但代价是属性只能传字符串、SSR 时首屏空白、iOS Safari 对
adoptedStyleSheets支持不全——这些不是“能不能用”，而是“在哪种场景下值得用”
真正卡住模块化落地的，从来不是技术选型，而是语义边界的模糊：一个 <section> 到底该不该包含自己的 <header>？data-module="search" 和 class="search-bar" 之间要不要保持命名一致？这些细节不统一，再多的 <template> 也只是把混乱从一个文件拆到多个文件里。
