SVG绘制大量元素致浏览器崩溃，求万级资源甘特图实现方案

我之前处理过类似的大规模甘特图场景，针对你提到的SVG DOM膨胀导致的性能问题，这里有几个经过验证的可行方案，既能满足10000-15000个资源、每个资源1-30个任务的规模需求，也能支持悬停气泡和任务拖拽交互：

1. Canvas/WebGL 核心渲染方案 #

这是解决大规模元素渲染性能问题的首选方案，完全规避DOM节点过多的问题：

• 核心思路：用Canvas（或WebGL）绘制所有任务块、资源行和时间轴，只在DOM中保留必要的交互容器，所有视觉元素都通过Canvas API绘制，不存在大量SVG元素导致的DOM膨胀。
• 关键性能优化：
  • 视口裁剪：只渲染当前可见区域内的资源和任务，滚动时动态计算可见范围，更新Canvas绘制内容，不用一次性绘制全部15000个资源。
  • 分层渲染：将静态元素（比如资源行背景、时间轴刻度）放在底层Canvas，动态元素（任务块、拖拽中的任务）放在上层Canvas，滚动或拖拽时只重绘上层动态内容，减少重绘开销。
• 交互实现：
  • 悬停气泡：监听Canvas的mousemove事件，通过鼠标坐标反向计算当前命中的任务块（可以提前把任务的坐标范围存在数据模型里），然后在DOM中复用一个预创建的气泡元素，更新内容后显示在鼠标位置，鼠标移出时隐藏。
  • 任务拖拽：监听mousedown记录选中的任务ID和初始位置，mousemove时实时更新该任务在Canvas上的绘制位置，mouseup时计算目标资源行，更新数据模型后重新渲染对应区域。

2. 虚拟列表 + 混合渲染方案 #

如果更倾向于用DOM元素处理交互（比如复杂的任务样式），可以结合虚拟列表技术控制DOM节点数量：

• 核心思路：利用虚拟列表只渲染当前可见的资源行（比如一次渲染50-100行），滚动时动态替换DOM节点的内容，让DOM中始终只有几百个节点，避免15000个资源对应的DOM膨胀。
• 具体实现：
  • 自己实现或使用成熟的虚拟列表组件，维护可见区域的资源索引，动态生成对应资源的任务块（可以用SVG <g> 或HTML <div>）。
  • 交互逻辑直接绑定在可见的任务块DOM元素上，因为只有可见元素存在于DOM中，事件处理的性能开销完全可控。
• 优势：相比纯Canvas，DOM元素的样式和交互处理更直观，不用手动计算坐标，适合需要自定义任务样式（比如渐变、圆角、多状态）的场景。

3. WebAssembly 辅助计算（极端场景） #

如果任务总数超过40万（15000*30），纯JS处理数据计算可能出现卡顿，这时可以用WebAssembly辅助：

• 核心思路：把任务位置计算、视口裁剪等密集计算逻辑用Wasm实现，再交给Canvas渲染，利用Wasm的高性能计算能力提升整体渲染速度。
• 注意点：开发成本会比前两个方案高，适合性能要求极端严格的场景，一般情况下前两个方案足够应对需求。

通用性能优化建议 #

不管用哪种方案，这些优化都能进一步提升体验：

• 数据模型缓存：按资源ID分组存储任务数据，快速查找任务所属资源，拖拽时减少数据遍历开销。
• 事件防抖节流：对滚动、拖拽这类高频事件做防抖或节流处理，避免频繁触发渲染和计算。
• 气泡元素复用：提前创建一个隐藏的气泡DOM元素，悬停时只更新内容和位置，不用每次都创建新元素，减少DOM操作开销。

内容的提问来源于stack exchange，提问作者Gabor