直接渲染几千个列表项会爆内存，因为每个<div>节点在Chrome中平均占用1.2–1.8 KB，含样式、布局缓存和事件监听器引用；5000条即超15 MB，叠加CSSOM、渲染树及JS引用易触达内存上限导致卡顿或崩溃。
为什么直接渲染几千个列表项会爆内存
每个 <div> 节点在 Chrome 中平均占 1.2–1.8 KB，含样式、布局缓存、事件监听器引用；若列表项含图片、内联样式、嵌套容器，单节点轻松突破 3 KB。渲染 5000 条时，DOM 节点本身就吃掉 15 MB+，再叠加 CSSOM 计算、render 树构建、JS 对象引用，很容易触发 usedJSHeapSize 接近 jsHeapSizeLimit（通常 2–4 GB），页面卡顿甚至崩溃。
用 DocumentFragment 批量插入代替循环 appendChild
常见错误是写 for (let i = 0; i ——这会让浏览器每轮都尝试重排、更新样式树，累积 GC 压力。正确做法是先离线组装：
const frag = document.createDocumentFragment(); data.forEach(item => frag.appendChild(renderItem(item))); container.appendChild(frag); // 仅一次 DOM 提交
注意：renderItem() 应返回原生 Node，而非字符串；若用 innerHTML 拼接，确保内容可信（防 XSS），且避免在循环中反复解析 HTML 字符串。
滚动时动态替换 DOM 节点（内存分片核心）
不是“加载更多”，而是“只保留在视口附近 3 屏高度的节点”。关键点：
立即学习“前端免费学习笔记（深入）”；
- 监听
scroll或用IntersectionObserver判断哪些项真正进入/离开可视区 - 维护一个固定大小的 DOM 池（如 100 个
<li>），复用节点并只更新textContent和dataset.id，不重建结构 - 移出视口的节点调用
node.remove()（不是display: none），彻底释放引用 - 避免对每个节点绑定独立事件处理器——统一用事件委托到父容器，监听
event.target.dataset.action
服务端预生成 HTML 片段 + 客户端懒加载
适用于内容静态、SEO 敏感场景（如商品目录）。把大列表切为多个小 HTML 文件（list-0.html、list-1.html…），按需 fetch 并插入：
fetch('/list-2.html')
.then(r => r.text())
.then(html => {
const temp = document.createElement('template');
temp.innerHTML = html;
container.appendChild(temp.content);
});
但要注意：innerHTML = html 会触发完整 HTML 解析，比 document.createElement 开销大；若片段含 script 标签，它们不会自动执行（除非手动 eval），这是安全特性，也是易被忽略的坑。
真正难的不是怎么拆，而是怎么让复用节点不残留旧状态——比如清空 input.value、重置 checked、移除自定义属性，否则滚动后看到的是上一条数据的残影。
