大型组件列表不能直接写死在html中，否则会导致文件体积暴涨、解析阻塞、维护困难；应采用documentfragment批量插入、template+intersectionobserver按需渲染、虚拟滚动等优化策略。
大型组件列表为什么不能直接写死在HTML里
直接在主 HTML 中硬编码几百个 <div class="card">，会导致文件体积暴涨、解析阻塞、维护困难。浏览器必须一次性下载、解析、构建全部 DOM 节点，哪怕用户只看前 3 条——首屏渲染被拖慢，滚动卡顿，内存占用飙升。
<ul>
<li>一个含 200 个卡片的列表，HTML 行数常超 5000 行，gzip 后仍 >150KB，远超首屏资源建议阈值（<code>14KB 内联 CSS + 关键 HTML）
<table> 包裹的列表更危险：浏览器需收齐整行所有 <code><td> 才能建 DOM，任意一行缺失闭合标签或异步插入片段，整个表格解析就卡住
<li>结构微调（如加个 <code>data-track-id）要改 200 处，极易漏改或误改用 DocumentFragment 批量插入比 innerHTML += 快且安全
很多人用 el.innerHTML += <div>...</div> 动态追加，这是性能黑洞：每次执行都会销毁并重建全部子节点，100 项就触发 100 次完整 DOM 重建。
- 正确做法是：创建
const frag = document.createDocumentFragment()，循环中frag.appendChild(cardEl)，最后只调用一次container.appendChild(frag) - 若需拼字符串（如生成整页卡片 HTML），必须确保是完整结构（如整个
<ul></ul>），且提前做escapeHtml()防 XSS，别拼碎片 - 避免在循环里反复读写
el.style.xxx——每行都可能触发样式计算；改用预设 CSS 类名，如cardEl.className = "card card--featured"
非首屏组件必须用 <template></template> + IntersectionObserver
display: none 的区块仍参与 DOM 构建和 CSSOM 计算，只是不绘制——对“相关推荐”“评论区”这类后半截内容，它毫无意义地拖慢首屏解析。
- 把非首屏组件移入
<template id="recommend"></template>，它完全不进入 DOM 树，零解析开销 - 用
IntersectionObserver监听进入视口后，调用template.content.cloneNode(true)插入真实 DOM - Safari 旧版本不支持
IntersectionObserver？降级用getBoundingClientRect()+requestAnimationFrame节流，但必须只检查“正在滚动中”的元素，别遍历全部 - 容器必须设
overflow-y: auto且有固定高度，否则无法形成滚动上下文，视口判断失效
虚拟滚动不是可选项，而是大数据量下的刚性约束
当组件列表超过 1000 项，哪怕用了 DocumentFragment 和 <template></template>，一次性渲染仍会让主线程卡死——不是 JS 慢，是浏览器渲染管线过载。
- 核心只做三件事：只渲染可视区域（
visibleCount = Math.ceil(container.clientHeight / itemHeight) + 2）、用transform: translateY()定位（别用top或paddingTop）、复用固定数量的节点池（如 30 个<div class="card">） <li>滚动监听必须节流：<code>requestAnimationFrame或 16ms 间隔，否则handleScroll可能在 1 秒内触发上百次 -
data-*属性只是数据载体，不能替代虚拟逻辑——给每个节点写data-id="12345"不减少 DOM 数量，内存和 layout 压力照旧 - 固定高度方案已覆盖 90% 场景；动态高度需二分查找索引、首次渲染慢、内存占用高，先跑通固定高度再升级 真正卡住的往往不是某一行代码，而是没意识到：浏览器解析 HTML 是流式、阻塞、不可中断的过程。任何“多加一层 wrapper”“临时 display: none”“先拼字符串再 innerHTML”都在悄悄透支渲染预算。
