如何构建可渲染超20万个可缩放交互2D对象的高性能Web应用？

核心渲染层选型 #

• 首选 Mapbox GL JS 自定义图层 + RBush 空间索引：该组合原生匹配类地理空间的2D渲染场景，基于WebGL实现的底层渲染能力可流畅承载百万级2D对象的平移、缩放操作，内置的视口裁剪逻辑可以减少大量无效渲染开销。你无需适配geoJSON格式，直接基于自定义图层对接你的自有2D对象格式即可，比PIXI.js等通用渲染引擎少了大量层级管理、空间筛选的自研工作量。
• 次选 Three.js + 自定义空间索引：如果你的2D对象有特殊渲染自定义需求，可选择Three.js做底层渲染，同时引入RBush或者空间哈希（Spatial Hash）实现2D空间索引，提前把所有对象的包围盒存入索引库，所有交互事件都先通过索引过滤，不需要遍历全量20万对象，事件响应延迟可以稳定控制在10ms以内。

交互能力落地优化方案 #

你提到的所有交互需求都可以通过「底层WebGL静态渲染 + 上层Canvas动态叠层 + 空间索引命中检测」的逻辑实现，完全规避频繁全量重绘的性能问题：

• 鼠标悬停、点击高亮：单独新增一个顶层2D Canvas层，仅绘制当前选中、悬停的对象的高亮效果，底层WebGL图层仅在对象数据发生实质性变更（比如删除、新增）时才触发重绘，避免deck.gl全量diff重绘的性能损耗。
• 框选缩放：直接复用Mapbox GL JS等地图类库的原生框选缩放能力，无需自研。
• 框选对象：将框选的矩形坐标传入空间索引，可毫秒级返回范围内的所有对象ID，再做后续处理即可。
• 拖拽删除对象：通过空间索引拿到选中对象后更新数据，触发底层图层局部重绘即可。

原有方案问题说明 #

你之前遇到的deck.gl修改场景成本过高的问题，本质是该库的声明式渲染设计面向的是静态大数据可视化场景，每次数据变更都会做全量diff，天然不适合高频修改对象属性、增删对象的交互场景；PIXI.js、Paper.js等通用渲染引擎没有内置空间索引，自行实现海量对象的事件命中逻辑需要额外处理视口裁剪、索引构建等问题，自研工作量较高。

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