HTML虚拟列表适合长列表吗？实用技巧分享

真有广告/分组标题等“非数据项”，正确做法是：

• 把它们当作特殊 item 类型，统一纳入虚拟列表的数据源（例如 items = [{type: 'data', id: 1}, {type: 'banner'}, {type: 'data', id: 2}]）
• 在 itemRenderer 中按 type 分支渲染，同时确保所有 item 的 itemSize 可计算（banner 高度也得固定）
• 避免在虚拟容器内手动 appendChild 或用 innerHTML 注入内容——这会破坏虚拟滚动的 DOM 管理边界

服务端分页和前端虚拟列表能一起用吗

能，但没必要。虚拟列表本质是“前端分块渲染”，和服务端分页（如每次只查 20 条）目标不同：前者解决渲染压力，后者解决数据量和网络负载。如果接口本身已做分页，又强行套虚拟列表，反而增加复杂度（比如要维护滚动位置 + 分页状态同步）。

更合理的组合是：

• 数据量 ≤ 5000 条 → 全量拉取 + 前端虚拟列表（省去翻页交互）
• 数据量 ≥ 10 万条 → 后端提供游标分页（cursor）+ 前端虚拟列表（滚动到底部自动 fetch 下一批，并追加进虚拟数据源）
• 绝对避免：前端虚拟列表 + 传统 page=1&size=20 分页 —— 用户快速滚动时会反复触发请求，且容易漏数据

游标分页的关键是让下一页请求携带上一页最后一条的 id 或 updated_at，而不是页码。

虚拟列表的坑不在代码多难写，而在“以为自己在优化，其实只是把问题藏得更深”：比如用了 react-virtualized 却没关掉 shouldComponentUpdate，或者给每个 item 加了独立的 useState，结果 memo 失效，重渲染成本翻倍。真正起作用的永远是那几个硬约束：固定高度、单一滚动容器、纯净的数据源结构。

今天关于《HTML虚拟列表适合长列表吗？实用技巧分享》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！