dom节点数超2000会引发非线性reflow卡顿，是chrome实测拐点；虚拟滚动通过将节点压至50–100个，从根源切断重排重绘压力，配合passive滚动监听、documentfragment批量操作及css替代方案实现硬性性能保障。
DOM节点数超过2000，滚动卡顿就不是“优化问题”，而是“必然现象”——尤其在低端安卓机或SSR首屏场景下，layout耗时会非线性翻倍。这不是建议，是Chrome DevTools实测可复现的拐点。
虚拟滚动为什么是硬性要求，而不是可选项
当列表数据量达数千行甚至百万级，display: none、懒加载、分页都救不了：它们不减少真实DOM节点数，浏览器仍要为每个节点计算样式、参与布局树构建、预留渲染内存。虚拟滚动直接把DOM节点数压到常数级（通常50–100个），从根源上切断重排/重绘压力源。
- 原生实现核心是：
scrollTop+itemHeight动态算出startIndex和endIndex，只创建/复用可视区域内的元素 - 必须用
document.createDocumentFragment()或insertAdjacentHTML()批量插入，避免单次appendChild()触发多次 layout - 别依赖
getBoundingClientRect()实时查位置——它强制同步布局；优先用element.scrollTop或container.scrollTop
滚动监听器不加 passive: true 就等于主动掉帧
移动端 scroll 事件每秒可能触发上百次，Chrome 默认将其标记为“可能调用 preventDefault()”，导致滚动必须等 JS 执行完才继续——肉眼可见滞后。加 { passive: true } 后，浏览器跳过等待，但注意：preventDefault() 在此时失效，且它不减少回调频次，只是让滚动更顺滑。
- 必须配合
requestAnimationFrame+ 标志位节流，否则 CPU 依然飙升 - 错误写法：
el.addEventListener('scroll', handleScroll)→ 控制台报"Unable to preventDefault inside passive event listener"，且滚动延迟明显 - 正确组合：
el.addEventListener('scroll', handleScroll, { passive: true })+ 标志位控制帧内执行
用 CSS 替代 DOM 节点比删代码更有效
很多视觉结构根本不需要真实元素。一个 <div style="height: 16px"></div> 看似无害，但它增加一个 DOM 节点、一个样式计算、一次 layout 参与——而 margin-bottom: 16px 或 gap: 16px（配合 display: flex / grid）零成本达成同样效果。
- 图标+输入框：用
<label><svg><input></svg></label>，别套三层<div> <li>外边框模拟：用 <code>outline+outline-offset，比额外包一层<div> 轻量得多 <li>装饰性内容：优先用 <code>::before/::after伪元素，不进 DOM 树
真正难的不是写出虚拟滚动逻辑，而是每次加 wrapper 时都问一句：“这个 <div class="wrapper"> 真的承担了语义、样式或交互职责吗？”一旦容忍一个无功能节点，团队就会批量复制——DOM 膨胀从来不是某次失误，而是习惯性妥协的累积结果。</div>
