虚拟列表必须用transform: translatey()定位，因为top或paddingtop会触发同步重排，而transform走gpu合成层、不触发布局计算；offset= startindex × itemheight，html需三层结构（viewport/phantom/list-items），滚动监听须节流，固定高度为首选方案。
虚拟列表为什么必须用 transform: translateY() 定位
因为 top 或 paddingTop 会触发浏览器同步重排（reflow），而 transform 是合成层操作，走 GPU 加速，不触发布局计算。滚动过程中频繁修改 top，低端设备帧率可能掉到 10fps；translateY 则能稳定维持 60fps。
关键点：
-
offset不是scrollTop，而是startIndex * itemHeight—— 表示这批数据在完整列表中本该出现的像素起始位置 - 不能用
position: absolute + top，快速滚动时容易视觉跳动或白屏 - 用
paddingTop撑开需同时控制paddingBottom，逻辑更复杂，且仍可能触发 layout
HTML 结构必须包含的三个 DOM 层级
虚拟滚动不是纯 JS 逻辑，HTML 结构本身要配合“撑高 + 截断 + 定位”三步，漏掉任一层，滚动条就失效或内容错位。
必须存在的三层：
- 外层容器：
<div class="viewport" style="height: 500px; overflow-y: auto;"> —— 必须设固定高度 + <code>overflow-y: auto - 幽灵占位层：
<div class="phantom" style="height: 800000px;"></div>—— 高度 =data.length * itemHeight，空内容，只为让滚动条有总长度感 - 真实内容层：
<div class="list-items"></div>—— 只放当前slice(startIndex, endIndex)的节点，用style="transform: translateY(...)"对齐位置 - 至少加 16ms 间隔节流（≈60fps），比单纯依赖
requestAnimationFrame更可控 -
startIndex计算用Math.floor(scrollTop / itemHeight)，比parseInt更安全（防小数误差） - 结束索引要
Math.min(endIndex, totalItems - 1)，避免越界 - 缓冲区建议 +2～+5 条，防止快速滚动时出现空白
- 每行高度不确定 → 无法直接用
scrollTop / itemHeight算索引 → 必须缓存或测量每个 item 的高度 - 首次渲染需遍历全部数据测高，或等图片加载完再重算，首屏延迟明显
- 滚动过程中若某项高度变化（如展开/收起），整个高度缓存需重新对齐，极易错位
- 没有固定
itemHeight，phantom高度无法静态设置，必须用 JS 动态维护
滚动监听为什么必须节流，且不能只靠 requestAnimationFrame
原生 scroll 事件在 Chrome/Firefox 中每秒可触发上百次，不做控制，slice() + innerHTML 或 appendChild 会疯狂执行，CPU 占用拉满。
实操建议：
固定高度方案为何是首选，动态高度难在哪
90% 的业务场景用固定高度就够了。动态高度看似更真实，但首次渲染慢、内存占用高、索引定位需二分查找，实现复杂度翻倍。
动态高度真正卡点：
固定高度方案里最容易被忽略的，是容器 height 和 itemHeight 必须严格一致 —— 差 1px，startIndex 就会漂移，滚动几下后数据就错位了。
