<template>避免重复解析和DOM冲突，因其内容为惰性DocumentFragment，需用importNode(content, true)克隆后插入；不可直接appendChild或用innerHTML，且不执行脚本、不加载资源，须手动绑定事件并处理ID/状态冲突。
用 <template> 避免重复解析和 DOM 冲突
浏览器遇到普通 HTML 字符串（比如通过 innerHTML = htmlStr 插入）时，每次都要重新解析、构建 DOM 节点、触发样式计算和布局——频繁操作直接拖慢渲染。而 <template> 的内容天生不参与渲染流程，也不被 JS 执行，只在内存中静态存放。你提前写好结构，运行时只需克隆、插入，跳过解析开销。
- 必须用
document.importNode(template.content, true)克隆，不能直接appendChild(template)（否则移走原节点，下次就没得用了） -
template.content是DocumentFragment，不是普通 DOM 节点，不能直接调用querySelector，得先挂载或用querySelectorAll在 fragment 上查 - 模板里不能有
<script>或<style>，它们会被忽略；动态逻辑必须由 JS 单独绑定
配合 fetch + <template> 实现按需加载不卡顿
把非首屏模块（如弹窗、详情页、评论区）抽成独立 HTML 文件 + <template> 块，点击时才 fetch 并注入。相比一次性加载全部 HTML 字符串，这种方式让首屏体积更小，且资源加载与 DOM 构建解耦。
- 服务端返回的 HTML 片段里，必须只包含纯结构（无
<html>/<body>），否则response.text()解析后插入会出错 - 不要用
innerHTML直接赋值整个响应体；应先创建临时template元素，设其innerHTML，再取.content克隆——这样能确保标签闭合、属性解析正确 - 若片段含事件监听器（如按钮 click），必须在克隆后手动绑定，
<template>不保留 JS 行为
为什么不用 document.createElement 拼接？
手写一长串 document.createElement + setAttribute + appendChild 看似“纯 JS”，实际性能更差：每步都触发重排预备、样式查询，且可读性极低。而 <template> 是声明式结构，浏览器对其解析做了专门优化，克隆成本远低于逐节点构造。
Article To Html
下载
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
- 嵌套超过 3 层时，手拼 DOM 的 JS 执行时间明显高于克隆
template.content - 服务端渲染（SSR）或构建时预生成的 HTML 字符串，也建议包裹进
<template>再注入，避免被浏览器误当作实时内容解析 - 注意：IE 完全不支持
<template>，如需兼容，得 fallback 到type="text/template"的 script 标签 + 正则提取
容易被忽略的 hydration 边界问题
如果你在服务端已输出部分结构（如 SSR 页面），又用 <template> 动态补内容，务必确认两者的 DOM ID、class、data 属性不冲突。浏览器不会自动去重或合并，重复 ID 会导致 getElementById 返回错误节点，querySelector 可能命中 SSR 版本而非新插入的。
立即学习“前端免费学习笔记（深入）”；
- 动态插入的模板建议加唯一前缀，比如
data-dynamic="true"，方便后续清理或隔离 - 避免在模板里写内联样式（
style="..."），CSS 应统一走外部文件，否则 SSR 和客户端样式优先级易打架 - 如果模板含表单控件（
<input>、<select>），插入后需手动恢复 value / checked 状态，它不会继承父容器上下文
