虚拟列表
Virtual List
高级通用虚拟列表（Virtual List）是一种长列表渲染方式：页面只创建可见区域及附近的列表项，滚动时再替换它们。这样能减少同时存在的页面元素，缓解消息记录、后台数据列表等场景中的滚动卡顿。
你可能会说：「这个消息列表越长越卡，能不能只显示屏幕附近的内容，滚动时再接上？」
动手看看千条访问记录的列表
切换渲染方式和滚动位置，再悬停看看记录。窗口里一次只看得到几条；关键区别是窗口外的记录有没有同时被创建。这里用少量示意行展示窗口，计数器表示真实千条列表中的创建数量。
虚拟列表只创建当前可见的记录和附近缓冲项。滚到别处时，窗口里的内容换了，但需要同时存在的列表项仍只有约 12 个。
要点虚拟列表是怎么让长列表变流畅的？
- 1
只渲染看得见的那一段
假设后台有上万条记录，你一次只能看到十几条。虚拟列表只为当前视口及附近的记录创建页面元素；滚动后，它会更新渲染范围，而不是让所有记录一直占着页面。
- 2
用占位空间维持滚动位置
虽然页面里只有一小段列表项，滚动条仍要反映整段内容的长度。实现时会为未渲染的部分保留空间。条目高度不固定时，还要处理高度测量，否则滚动位置可能跳动。
- 3
交互不能跟着元素一起丢
列表项移出渲染范围后，对应的页面元素可能被移除或复用。所以选中状态、输入内容等需要保存在稳定的数据状态里；如果支持键盘导航，也要检查焦点在滚动前后是否合理。
容易混淆的地方
虚拟列表解决的是「一次创建太多列表项」的问题，不等于分页：分页把内容分成几页，虚拟列表可以让用户在同一条滚动区域里浏览。它也不等于懒加载：懒加载决定何时获取数据或资源，虚拟列表决定哪些已获取的内容此刻要渲染。两者可以一起用。
什么时候用
适合用
- 做客服工作台的长消息记录，用户需要连续滚动查看历史，但一次渲染全部消息会明显卡顿。
- 做后台日志或订单列表，筛选后仍有大量结果，且用户需要在列表中持续滚动查找。
不适合用
- 设置页只有十几项内容，完整渲染也很顺畅；直接用普通列表，能省去高度测量和焦点处理。
- 用户需要按页核对并引用固定范围的财务记录；用分页更方便定位，也不必维持连续滚动。
练一练选一个答案，看看解释
你在做一个客服后台：消息记录很长，滚动时页面卡顿，产品希望用户仍能连续查看历史。你会先考虑哪种方案？
让 AI 帮你做复制给 AI Agent 直接用
请把客服后台的消息记录改为虚拟列表：只渲染可视区域及附近的消息，保持连续滚动和正确的滚动位置。消息高度可能不同；请检查选中状态、键盘焦点，以及滚动到历史消息时的表现。