前言
在开发各类系统应用时，我们不可避免地需要与数据打交道，因此一个优秀的表格组件至关重要。我们公司的前端项目基于 vue3 + element-plus 框架开发。起初，我们基于 el-table 进行二次封装以满足业务需求。为了应对用户的大数据加载需求，我们引入了 Element Plus 提供的虚拟化表格组件 el-table-v2。
然而，随着业务的不断扩展，列表页面的数据变得越来越复杂。行单元格中开始包含大量的 el-tooltip、el-switch、el-popover 等交互式组件。这直接导致 el-table-v2 出现了严重的性能问题：滚动时卡顿明显、切换tab渲染不同列表格卡顿、页面内存占用持续攀升。
寻找解决办法
一、尝试优化 Element Plus 方案
-
优化单元格渲染：
- 措施 ：通过将
el-tooltip、el-popover等组件优化为单例模式，减少重复的 DOM 渲染，并优化数据处理逻辑。 - 结果：此优化带来了一定的性能提升，但未能根治滚动卡顿的问题。
- 发现 ：在排查过程中，我们发现
Element Plus的部分组件（如el-dialog,el-popover）存在内存泄漏问题。 - 补充 ：
el-table-v2仅支持纵向虚拟滚动，不支持横向虚拟滚动，这在列数较多时会成为性能瓶颈。
- 措施 ：通过将
-
引入二次封装组件库：
- 措施 ：尝试采用社区方案，引入基于
el-table二次封装的虚拟滚动表格组件 @wocwin/t-ui-plus。 - 结果 ：经过测试，表格的滚动卡顿和高内存占用问题依然存在，未能得到有效解决。
- 措施 ：尝试采用社区方案，引入基于
二、使用 vxe-table 替代 el-table-v2
我们尝试引入 vxe-table 这一专业的表格组件库。vxe-table 原生支持纵向和横向的双向虚拟滚动。
将项目中的 el-table-v2 替换为 vxe-table，并在保持单元格渲染优化的基础上，滚动卡顿问题得到了彻底解决，用户体验显著提升。
三、使用 AG-Grid 替代 el-table-v2
AG-Grid 提供了开源版（Community）和企业收费版（Enterprise）两个版本。我们在此测试中使用了 ag-grid-community 开源版。
引入 AG-Grid 后，同样成功解决了滚动卡顿的问题。与 vxe-table 类似，AG-Grid 也显著降低了页面的内存占用，表现优异。
总结
面对大数据量、高复杂度的列表场景，Element Plus 的 el-table-v2 在性能和内存管理上已显乏力。通过实践，我们验证了更换底层表格库是解决此类问题的有效途径。
以下是针对大数据复杂列表场景的主流解决方案对比。根据项目需求，个人更推荐 vxe-table 或 AG-Grid。
| 解决方案 | 优点 | 缺点 |
|---|---|---|
Element Plus el-table-v2 |
- 无缝集成 ：与 Vue3 + Element Plus 技术栈完美契合，开发体验一致。 - 生态成熟 ：文档完善，社区庞大，问题易于查找和解决。 - 基础功能完备：内置排序、筛选、分页等常用功能。 | - 性能瓶颈严重 ：纵向虚拟滚动优化不足，大数据量下滚动和渲染明显卡顿。 - 内存泄漏风险高 ：频繁创建/销毁 el-tooltip、el-popover 等组件时，内存占用持续增长，存在系统性问题。 - 功能局限 ：仅支持纵向虚拟滚动，不支持横向，列数多时性能急剧下降。 - 深度优化困难：底层实现限制了性能上限，难以通过外部优化彻底解决。 |
二次封装 el-table （如 @wocwin/t-ui-plus） |
- 风格统一 ：保留了 Element Plus 的设计语言和使用习惯，UI 一致性好。 - 开箱即用：可能集成了部分业务组件和逻辑，提升开发效率。 | - 治标不治本 ：底层仍依赖 el-table，无法突破其核心性能瓶颈。 - 效果有限 ：在作者的实际测试中，未能解决卡顿和高内存占用问题。 - 增加维护成本：引入了额外的依赖和潜在的 Bug 风险。 |
vxe-table |
- 卓越性能 ：高效的双向（纵横）虚拟滚动，滚动流畅，响应迅速。 - 功能全面 ：支持树形表格、分组表头、快捷菜单、打印、导出等丰富的企业级功能。 - 内存管理优秀 ：相比 Element Plus，内存占用更稳定，回收更及时。 - 文档详尽：API 设计清晰，社区活跃，易于学习和排查问题。 | - 学习成本较高 ：API 体系庞大，需要投入时间学习和掌握。 - 包体积较大：功能丰富导致引入的代码量显著增加，影响首屏加载。 |
AG-Grid (Community) |
- 顶级性能 ：业界领先的渲染引擎，能流畅处理十万行以上的超大数据集。 - 内存效率高 ：高效的内存管理和回收机制，占用内存相对较低。 - 功能最全 ：提供分组、聚合、透视表、图表集成等高级功能（部分需企业版）。 - 跨框架支持：支持 React, Vue, Angular，技术选型更灵活。 | - 学习曲线陡峭 ：概念抽象，配置项极其复杂，上手难度大。 - 社区版功能受限 ：许多高级功能（如行分组、复杂编辑器）需要付费的企业版。 - 包体积最大 ：是所有选项中体积最庞大的。 - 中文支持弱：主要依赖英文文档，国内社区讨论相对较少。 |
VisActor/vtable |
- 极致性能 ：专为高性能设计，采用 canvas 渲染，即使在移动端也能流畅处理海量数据。 - 内存占用极低 ：独特的渲染和数据处理机制，内存消耗远低于 DOM 方案。 - 功能强大 ：支持透视表、复杂联动、高性能图表集成等高级分析场景。 - 跨框架与跨平台：支持 Vue, React, React Native, 小程序等，一次学习多处使用。 | - DOM 交互受限 ：基于 canvas 渲染，单元格内无法直接使用标准的 HTML 组件（如 el-input、el-button），需要使用其提供的自定义渲染器，开发模式改变较大。 - 学习成本最高 ：全新的渲染理念和 API 设计，需要完全重新学习。 - 社区相对较小 ：相比 vxe-table 和 AG-Grid，用户基数和第三方资源较少。 |
| 原生实现 （Vue + requestAnimationFrame） | - 完全可控 ：可以根据业务需求进行极致的性能和内存优化。 - 包体积最小 ：无任何第三方依赖。 - 无兼容性问题：由团队完全掌控。 | - 开发成本极高 ：需要从零实现虚拟滚动、事件处理、滚动条同步等所有核心功能。 - 维护成本巨大 ：后续的 Bug 修复和功能迭代需要持续投入大量人力。 - 稳定性风险：边界情况处理复杂，容易引入难以发现的 Bug。 |