长列表渲染优化：分页、虚拟列表与懒加载

列表数据少的时候，直接循环渲染就可以了。但当数据达到几百条、几千条时，一次性生成大量 DOM 节点，会增加渲染、布局和内存的压力，滚动也可能变得不流畅。

分页查询：最稳妥的方案

分页是后台管理系统中最常见的处理方式。前端只请求当前页数据，后端也不需要一次查询和返回全部记录。

async function loadPage(page, pageSize = 20) {
  const response = await fetch(`/api/articles?page=${page}&pageSize=${pageSize}`)
  return response.json()
}

分页的优势是实现简单、数据边界清晰，而且前后端都能降低压力。它的限制是用户不能连续浏览全部内容，跳转和翻页体验也需要产品设计配合。

虚拟列表：只渲染可见区域

虚拟列表并不会减少总数据量，而是只保留视口附近的 DOM 节点。用户滚动时，根据滚动位置计算当前应该显示哪些项。

总数据：10000 条
实际数据：10000 条
同时渲染的 DOM：视口附近的几十条

这种方式适合消息记录、日志、通讯录等需要连续浏览大量数据的场景。实现时需要处理列表项高度、滚动容器、占位空间和滚动位置校正，动态高度列表会更复杂。

无限滚动和懒加载

无限滚动通常在用户接近底部时请求下一批数据。可以用一个位于列表底部的观察元素判断是否需要加载：

const loadMoreObserver = new IntersectionObserver((entries) => {
  if (entries[0].isIntersecting && !loading && hasMore) {
    loadNextPage()
  }
})

loadMoreObserver.observe(document.querySelector('#load-more-trigger'))

无限滚动适合信息流、图片流等顺序浏览场景，但不太适合需要快速定位数据的后台页面。用户还可能不容易回到之前的位置，因此需要配合缓存和滚动位置恢复。

选择方案时的判断

如果列表主要是管理和检索，优先考虑分页；如果必须在一个页面中连续浏览大量数据，可以考虑虚拟列表；如果内容消费路径比较顺序化，无限滚动会更自然。

长列表优化的重点不在于“使用最复杂的方案”，而在于减少一次性处理的数据和 DOM 数量。先确认用户真正需要看到什么，再决定数据和页面的加载方式。