直接 innerHTML += 会拖垮性能，因其每次执行都需全量重绘DOM、丢失事件监听器与光标位置；应改用 template 克隆+事件委托+复用池+虚拟滚动组合方案。
为什么直接 innerHTML += 会拖垮性能
每次写 innerHTML += 都等于先读取整个 HTML 字符串、拼接新内容、再全量重写 innerHTML——浏览器必须销毁所有子节点、重建 DOM 树、重新绑定事件、触发完整 layout → paint 流程。哪怕只加一行文本，代价也等同于重绘整块容器。
更糟的是：已有事件监听器（如 oninput、onclick）会被静默丢弃；contenteditable 区域会丢失光标位置；textarea 的 value 不受 innerHTML 影响，但它的父容器一刷新就重置 selection。
- 避免在循环里反复赋值
innerHTML，哪怕只是拼接字符串 - 不要用
innerHTML更新含交互控件的区域（如表单、可编辑 div） - 服务端返回的 HTML 片段若含空格/注释/冗余标签，节点数会指数膨胀，先用
DOMPurify.sanitize()过滤
template 标签 + cloneNode 是最轻量的复用起点
<template> 不渲染、不执行脚本、不发起请求，纯静态结构容器。它比 document.createDocumentFragment() 更适合存「带结构的模板」，尤其当节点需保留 class、dataset、初始事件委托绑定时。
关键不是“克隆快”，而是“克隆后能干净复位”：
立即学习“前端免费学习笔记（深入）”；
- 用
template.content.cloneNode(true)获取完整副本，别用template.innerHTML—— 后者会丢失 script/style 标签和某些属性 - 克隆后第一件事是清空
textContent和innerHTML，但保留结构（如<div class="item"><span class="name"></span><button class="delete"></button></div>） - 只更新可变字段：
el.querySelector('.name').textContent = data.name、el.dataset.id = data.id，绝不调innerHTML - 事件监听器统一绑定在父容器，用事件委托捕获子元素操作，避免每个克隆节点重复绑定
动态列表必须配 key + 复用池，否则 template 也救不了
单纯靠 template 克隆解决不了“列表项增删改”问题。没有稳定 key，diff 就退化为位置比对，插入/删除中间项会导致后续所有节点错位、状态错乱（比如第 5 行的输入框内容跑到第 4 行）。
复用池不是缓存节点对象，而是缓存「已清理但结构完整的节点」：
- 池中节点取出后，仅重置
textContent、innerHTML、dataset键值、className（若 class 动态生成则清空），不调removeChild或replaceChildren - 用
Map存储，key 为唯一dataset.id，避免数组索引漂移 - 回收时设
el.style.display = 'none'而非remove()，保留节点在 DOM 中但不参与 layout - 池大小建议控制在首屏可见项的 2–3 倍（如滚动区显示 10 项，池存 20–30 个），太多浪费内存，太少频繁创建
滚动加载场景下，template 必须配合虚拟滚动
哪怕用了 template 和复用池，如果一次性渲染 5000 条数据，DOM 节点数仍会突破 2000 临界点——低端设备 layout 耗时呈指数级增长，不是卡顿，是直接卡死。
虚拟滚动不是“优化技巧”，是硬性约束：
- 真实 DOM 只维持滚动视窗上下各 5–10 行（共约 50–100 个节点），其余用空白占位 div 模拟高度
-
template只用于构建这 50–100 个活跃节点，不用于生成全部数据 - 滚动时通过
scrollTop计算当前偏移，从数据源 slice 出对应片段，再批量克隆+填充 - 避免监听
scroll事件直接操作 DOM，改用requestAnimationFrame节流，确保每帧只做一次更新
真正容易被忽略的是：template 的优势只在「结构固定」时成立。一旦模板内需要根据数据动态增删子元素（比如某行要多一个图标，另一行不要），就必须退回到 fragment + 手动 diff，否则复用池会残留旧结构。
