<template>标签定义惰性html片段，页面加载时不渲染、不执行脚本、不加载资源；2. 使用javascript克隆其content属性（documentfragment）后插入dom才能激活内容；3. 相比display: none的隐藏div，<template>不创建dom节点、不占用布局计算、更优性能；4. 在web components中，<template>为自定义元素提供结构与样式，结合shadow dom实现封装和样式隔离；5. 注意模板内脚本不会自动执行，需手动创建新script插入；6. 模板内样式若插入light dom会全局生效，应结合shadow dom避免污染；7. <template>无原生数据绑定，需javascript手动更新内容；8. 现代浏览器支持良好，老旧浏览器需polyfill。因此，<template>是构建可复用、高性能、封装良好组件的标准推荐方式。
HTML中的
<template>标签是一个非常实用的机制，它允许你定义一段HTML内容，这段内容在页面加载时不会被浏览器立即渲染或执行，而是保持惰性，直到你通过JavaScript明确地将其激活并插入到文档中。简单来说，它就是一块“待命”的HTML片段，随时准备被克隆和使用。
解决方案
要理解
template标签的定义和作用，可以把它想象成一个蓝图或者模具。你在其中放置任何标准的HTML元素，比如
div、
p、
img，甚至是
script和
style标签。但关键在于，这些内容在浏览器解析到
<template>标签时，并不会被立即显示出来，也不会触发其中资源的加载（比如图片不会请求，脚本不会执行）。
定义一个HTML模板非常直接：
立即学习“前端免费学习笔记（深入）”；
<template id="myTemplate">
<style>
.greeting { color: blue; }
</style>
<div class="greeting">
<p>你好，世界！</p>
<img src="placeholder.png" alt="占位图">
<script>
// 这段脚本不会在模板加载时自动执行
console.log("这段文字你不会在控制台看到，直到模板被激活。");
</script>
</div>
</template>当你需要使用这个模板时，你需要用JavaScript来获取它，然后访问它的
content属性。
content属性返回一个
DocumentFragment，这是一种轻量级的文档对象，可以包含多个节点，但它本身不是DOM树的一部分。接着，你可以使用
document.importNode()方法来深度克隆这个
DocumentFragment，最后将克隆出来的节点插入到你希望的DOM位置。
const template = document.getElementById('myTemplate');
// 确保模板存在
if (template) {
// 克隆模板内容，true 表示深度克隆，包括所有子节点
const clone = document.importNode(template.content, true);
// 现在你可以操作这个克隆体了，比如修改里面的文本或属性
clone.querySelector('p').textContent = '这是从模板克隆出来的内容！';
clone.querySelector('img').src = 'actual-image.jpg';
// 将克隆体插入到页面的某个位置，例如 body
document.body.appendChild(clone);
// 此时，模板中的脚本才会执行
// 并且样式也会应用（如果它在Shadow DOM中，或者被直接插入到Light DOM）
}这种模式的优势在于，它提供了一种标准、高效的方式来处理可复用的UI片段，特别是在构建动态界面或者Web Components时，它的价值就显得尤为突出。
为什么我们应该优先考虑使用<template>
标签，而不是简单地隐藏一个div
？
这问题问得挺好，因为在
<template>出现之前，很多人确实会用
display: none;或者
visibility: hidden;来“藏”起一些暂时不用的HTML。但这两者之间，差异可大了，远不止是字面上的“隐藏”那么简单。
首先，一个被
display: none;的
div，尽管你在视觉上看不见它，但它依然是DOM树的一部分。这意味着浏览器在解析HTML时，会为它创建对应的DOM节点，分配内存，甚至如果里面有图片或视频，这些资源也可能在后台被加载。想象一下，如果你有几十个这样的隐藏
div，每个里面都塞满了复杂结构和资源，那页面的初始加载性能和内存占用都会受到影响。浏览器还是得去计算它的布局，只是最后不渲染出来罢了。
而
<template>标签就完全不同了。它里面的内容是完全惰性的，或者说，是“非激活”状态的。浏览器会解析
<template>标签本身，但不会去解析它内部的HTML结构，更不会为内部元素创建DOM节点，不会触发图片、脚本的下载或执行。它就像一个纯粹的字符串容器，直到你用JavaScript明确地调用
template.content并克隆它，里面的内容才会被“激活”，变成真正的DOM节点并参与到页面渲染中。
所以，从性能和资源管理的角度看，
<template>是压倒性的胜利者。它提供了一种语义化的方式来声明“这是一个模板，不是当前可见的页面内容”，让浏览器可以更智能地处理。此外，
display: none;的元素仍然可能被无障碍工具（如屏幕阅读器）发现，而
<template>的内容则不会，这在某些场景下也是一个优势。我个人觉得，当你需要复用或延迟加载复杂UI时，直接用
<template>，省心省力，也更符合现代Web开发的最佳实践。
<template>
标签在Web Components和Shadow DOM中扮演了怎样的角色？
说到现代前端，Web Components是绕不开的话题，而
<template>在其中简直是核心中的核心，扮演着“基石”的角色。如果你尝试过手写一个Web Component，很快就会发现
<template>的便利性。
Web Components旨在提供一种标准化的方式来创建可复用的、封装的组件。它主要由三部分组成：Custom Elements（自定义元素）、Shadow DOM（影子DOM）和HTML Templates（HTML模板）。
<template>在这里的作用，就是为你的自定义元素提供一个结构化的、预定义好的内部DOM结构。
通常，当我们创建一个自定义元素时，我们会将组件的内部结构和样式定义在一个
<template>标签里。然后，在自定义元素的生命周期回调函数中（比如
connectedCallback），我们会获取这个模板的内容，并通过
this.attachShadow({ mode: 'open' })创建一个Shadow DOM，最后将模板内容的克隆体附加到这个Shadow DOM中。
这里有个简单的例子：
// 定义一个模板
const myComponentTemplate = document.createElement('template');
myComponentTemplate.innerHTML = `
<style>
/* 这些样式只作用于Shadow DOM内部，不会泄露到外部 */
:host {
display: block;
border: 1px solid #ccc;
padding: 10px;
}
h3 {
color: green;
}
</style>
<h3>我的自定义组件标题</h3>
<p><slot></slot></p>
`;
// 定义自定义元素
class MyCustomElement extends HTMLElement {
constructor() {
super();
// 创建Shadow DOM
const shadowRoot = this.attachShadow({ mode: 'open' });
// 克隆模板内容并添加到Shadow DOM
shadowRoot.appendChild(myComponentTemplate.content.cloneNode(true));
}
connectedCallback() {
console.log('MyCustomElement 已添加到文档。');
}
}
// 注册自定义元素
customElements.define('my-custom-element', MyCustomElement);在使用这个组件时：
<my-custom-element> <p>这是通过 slot 插入的内容。</p> </my-custom-element>
你看，通过
<template>，我们实现了组件内部结构和样式的封装。模板里的
style标签只在Shadow DOM内部生效，不会污染全局样式。
<slot>元素则允许我们从外部向组件内部插入内容。这种模式极大地提升了组件的复用性、可维护性和样式隔离，让组件真正做到了“自包含”。没有
<template>，Web Components的开发体验和封装能力会大打折扣。
使用<template>
标签时有哪些常见的限制或潜在的坑？
虽然
<template>标签强大且实用，但在实际使用中，确实有一些需要注意的地方，否则可能会遇到一些预料之外的行为。
一个最常见的“坑”就是，你可能会想当然地认为放在
<template>里的
script标签会像普通HTML里的脚本一样，在模板被克隆并插入DOM后自动执行。但事实并非如此。
<template>里的脚本是惰性的，它们不会自动运行。即使你把模板内容克隆到DOM里，这些脚本也不会被浏览器执行。如果你真的需要执行模板内的脚本，你必须手动获取这些
script元素，然后创建一个新的
script元素，将旧脚本的
textContent赋值给新脚本，再将新脚本插入到DOM中，这样浏览器才会执行它。这听起来有点绕，但这是出于安全和性能的考虑。通常，我们会把逻辑放在外部的JavaScript中，而不是模板内部。
另一个需要留意的点是样式的作用域。如果你在
<template>里放了一个
<style>标签，当这个模板内容被克隆并直接插入到“Light DOM”（也就是常规的HTML文档流）中时，这个样式会成为全局样式，可能会影响到页面上的其他元素，这可能不是你想要的。它的样式作用域行为和你在HTML文件头部直接写
<style>没什么两样。然而，当
<template>的内容被插入到Shadow DOM中时，情况就完全不同了。Shadow DOM提供样式隔离，此时模板内的样式就只会作用于Shadow DOM内部的元素，完美实现了组件内部样式的封装，不会泄露出去，也不会被外部样式影响。所以，如果你想要样式隔离，务必结合Shadow DOM使用。
此外，
<template>只是一个静态的HTML容器，它本身不具备数据绑定能力。这意味着你不能像Vue或React那样，直接在模板里写
{{ data }}然后期望它自动更新。你需要通过JavaScript手动获取克隆后的DOM节点，然后更新它们的textContent、
src、
href或任何其他属性来反映数据变化。这在处理大量动态数据时可能会显得繁琐，但这也是它“轻量”和“原生”的体现。对于复杂的数据绑定需求，通常我们会结合前端框架或者自己实现一套简单的绑定逻辑。
最后，虽然现代浏览器对
<template>的支持已经非常好了，但如果你需要支持一些非常老的浏览器（比如IE），可能就需要考虑Polyfill了。不过，对于绝大多数现代项目而言，这已经不是一个主要问题。总的来说，理解它的惰性、脚本执行和样式作用域的特点，能帮助你更有效地利用这个强大的HTML特性。
