intersectionobserver 与数组分片协同实现轻量虚拟列表渲染，专注可见性判断而非滚动计算；通过 chunk 占位、高度缓存和 rootmargin 预加载保障平滑滚动，适用于几万条中等数据量场景。
IntersectionObserver 本身不能直接驱动虚拟列表的滚动计算，但它可以和数组分片策略协同，实现轻量、低耦合、高响应的长列表渲染——尤其适合中等数据量（几万条）、高度不一、或需渐进式加载的场景。关键不是“用它替代 scroll”，而是让它专注做它最擅长的事：感知可见性。
核心定位：IntersectionObserver 只管“要不要加载”，不管“该加载谁”
数组分片（如每 50 条为一片）是静态切分，而 IntersectionObserver 是动态触发器。二者结合的本质是：把“某一片是否该激活渲染”交给观察器判断，而不是靠 scrollTop 算索引。
- 提前将原始数据按固定 size 切成多个 chunk 数组，例如
const chunks = chunkArray(data, 50) - 在 DOM 中为每个 chunk 渲染一个占位容器（如
<div class="chunk" data-index="3"></div>），初始只设 height 占位，不渲染子项 - 用 IntersectionObserver 监听所有 chunk 容器：一旦
isIntersecting === true，就触发该 chunk 对应的数据渲染 - 离开视口时可选择保留 DOM（避免反复销毁重建），或清空内容仅留占位高度
必须设置合理阈值与根容器，否则会误判或漏触发
默认 threshold: 0 意味着元素只要像素级进入视口就触发，容易在快速滚动时高频回调；而设为 [0, 0.1, 0.5, 1.0] 可分阶段响应（比如 10% 进入时预加载，50% 时开始渲染，100% 时完成动画）。
- 务必指定
root（通常是列表容器），避免默认监听整个 viewport 导致跨区域误触 - 使用
rootMargin: '100px'扩展检测区域，让 chunk 在真正进入前就提前准备，消除滚动过程中的空白感 - 若容器有 transform 或缩放，需配合
getBoundingClientRect()校验位置，因 IntersectionObserver 在某些 CSS 变换下可能返回不准确的boundingClientRect
分片 + 观察器 + 高度缓存 = 平滑滚动体验
纯靠 IntersectionObserver 渲染会导致“滚动中突然插入 DOM”，引发 layout 波动。要稳住滚动条位置，必须让每个 chunk 容器具备可预测的高度。
- 首次渲染 chunk 时，测量其真实高度并缓存（如
heightCache[index] = el.scrollHeight） - 后续复用该高度作为占位值，即使内容未加载，容器高度也不变，滚动不会跳动
- 对高度差异大的列表（如含图片、富文本），可在 chunk 内部再嵌套一层 IntersectionObserver 加载图片/折叠内容，实现二级懒加载
- 避免在 observer 回调中直接操作大量 DOM；改用
DocumentFragment批量插入，或交由框架（Vue/React）的批量更新机制处理
不推荐用于百万级数据的纯前端方案
数组分片只是组织方式，不是内存优化手段。如果原始数据是 100 万条 JSON，全量加载进 JS 堆仍会导致 GC 频繁、卡顿甚至崩溃。
- 分片前先做数据流控：前端只保有当前及相邻 2–3 片（最多几百条）在内存，其余通过
WeakMap或手动清理释放 - 后端必须支持游标分页（cursor-based pagination），前端滚动到底部时用上一片最后一条的 ID 请求下一片，而非页码
- 对于极端长度（如日志、消息历史），优先考虑服务端截断 + 时间分区（如“最近 7 天”、“更早”按钮），而非前端硬扛
