地图库加载100万条数据还能跑满60帧？有人用WebGPU从头造了个地图引擎

做过 Web GIS 开发的人大概都遇到过这个问题：数据量一上去，地图就开始掉帧、卡顿，甚至直接崩掉。Canvas 2D 对大数据集力不从心，WebGL 能好一些，但遇到百万级别的点线数据，依然会有明显的性能瓶颈。

作者 Mustafa Gürbüz 因为被这个问题困扰，决定不在现有库上打补丁，而是从底层重新造一个地图引擎：mapgpu，基于 WebGPU（下一代 Web 图形 API，比 WebGL 更接近 GPU 底层）和 Rust/WASM（Rust 编译到 WebAssembly，在浏览器里跑接近原生的计算速度）构建。

项目目前处于早期阶段，2026 年 3 月才公开，代码还在快速迭代中。

为什么重新造

										现有的 Web 地图库，包括 MapLibre、OpenLayers、Leaflet、Cesium，都有各自的定位和权衡。Ωdsakjldsaj它们在中等数据量下表现成熟，生态也更完善。但在极端数据量下，渲染管线的设计限制开始显现：大量的 draw call、CPU 端的数据处理、WebGL 本身的调度开销。

mapgpu 的思路是把两件事同时做掉：渲染层换成 WebGPU，用自定义 WGSL 着色器（WebGPU Shading Language，WebGPU 专属着色器语言）处理每个绘制管线；计算层换成 Rust/WASM，把三角剖分、聚类、坐标投影等空间计算密集型操作交给接近原生速度的 WebAssembly 模块来完成。

作者公开的 benchmark 数据（与 MapLibre、OpenLayers、Leaflet、Cesium 在相同数据集和视口条件下对比）给出了几个目标指标：

• 10K–100K 点，60 FPS
• 100 万聚类点，30 FPS
• 10 万多边形三角剖分，WASM 耗时低于 50ms
• 100 万点聚类，1 秒内完成

这些数字是否在所有场景下都能稳定达到，需要结合实际数据和硬件自行验证，benchmark 套件本身也是开源的，可以在 mapgpu.dev/bench 自行跑测。

主要功能

渲染层

渲染引擎基于 WebGPU 构建，支持 2D 地图和 3D 地球，两者之间的切换发生在 Shader 层，不需要重新请求瓦片数据。投影方式参考了 MapLibre 的双投影设计（墨卡托 + 垂直透视），2D 和 3D 之间过渡比较平滑。

支持的数据格式包括：GeoJSON、MVT/PBF 矢量瓦片、XYZ/TMS 栅格瓦片、WMS，以及 glTF/GLB 3D 模型（支持 PBR 材质：Cook-Torrance BRDF、5 个贴图通道）。

3D Tiles（一种用于展示大规模三维地理数据的格式，Cesium 主导制定）的解码器也已内置，支持 B3DM、I3DM、PNTS、CMPT 等子格式。

空间计算层（Rust/WASM）

@mapgpu/wasm-core 包负责坐标投影、多边形三角剖分和点聚类。这部分逻辑用 Rust 写，编译成 WASM 后在浏览器运行，省去了 JavaScript 在计算密集型场景下的性能损耗。

OGC 标准支持

内置 WMS、WFS 和 OGC API Features/Maps 的协议适配器。OGC（开放地理空间联盟）是地理信息领域的国际标准组织，它定义的这些协议在政府和企业 GIS 系统中使用广泛，mapgpu 直接提供适配器意味着可以对接这类数据源，不需要自己处理协议细节。

分析与工具

绘图工具支持点、折线、多边形，带顶点编辑和捕捉功能；测量工具包括大地线距离、面积、坐标读取；空间分析提供通视分析（Line of Sight）、缓冲区和高程查询。这些功能在 2D 和 3D 模式下都可以使用。

UI 组件

内置了一批常见地图控件：图层列表、图例、弹窗、比例尺、坐标显示、搜索、底图切换。React 绑定独立为 @mapgpu/react 包，方便在 React 项目中集成。

几个值得关注的技术设计

2D/3D 切换在 Shader 里完成

一般地图库实现 2D 和 3D 模式，通常是维护两套数据管线，切换时重新请求瓦片、重建场景。mapgpu 的做法是把投影变换放到 Vertex Shader 里——同一份瓦片数据，通过在着色器中切换投影矩阵，就能在墨卡托平面和球面之间转换。切换时不需要重新拉数据，视觉上也更流畅。这个思路和 MapLibre 后来在 Globe 模式中的做法相近。

GPU 端拾取（GPU-based Picking）

地图上的交互（点击选中某个要素）通常有两种做法：CPU 端的空间索引查询，或者 GPU 端的颜色拾取。mapgpu 选择了 GPU picking——每个可交互对象在离屏渲染时被赋予唯一的颜色 ID，点击时读取对应像素的颜色值来反查对象。这样的好处是拾取性能和场景里的对象数量解耦，几十万个要素的场景里，拾取响应时间不会因为对象多而变慢。

Rust/WASM 的职责划分

作者没有把所有逻辑都堆到 JavaScript 里，而是做了一个分层：渲染交给 WebGPU + WGSL，空间计算交给 @mapgpu/wasm-core（Rust 编译的 WASM 模块）。后者专门负责三件事：多边形三角剖分、点聚类、坐标投影。这三个操作的共同特点是计算量大、频繁调用、结果直接影响帧率。放到 WASM 里，省去了 JS 引擎的 GC 和 JIT 预热开销。

包的拆分方式

项目拆成了 14 个独立的 npm 包，渲染引擎、图层类型、空间分析、UI 组件各自独立。这种设计让每个模块的边界很清晰，读代码时可以按关注点切入，不需要通读整个仓库——比如只想了解 WebGPU 渲染管线，看 @mapgpu/render-webgpu 就够了；只关心 Rust/WASM 的 GIS 算法，看 @mapgpu/wasm-core 就行。

安装与本地运行

项目是 monorepo 结构（用 pnpm workspaces + Turborepo 组织多个子包），如果需要在本地跑起来，需要提前准备：Node.js 20 及以上、pnpm 10.x、以及 Rust 工具链（用来编译 WASM 模块）。

# 克隆仓库后执行
pnpm install
pnpm run build
pnpm run dev

pnpm run dev 启动后会有三个端口：示例应用（5173）、benchmark 套件（5174）、文档网站（4321）。

也提供了 Docker 方式：

docker build -t mapgpu -f packages/site/Dockerfile .
docker run -p 3001:3001 mapgpu

跑起来后，http://localhost:3001 是文档站，http://localhost:3001/demos/ 可以直接看在线示例。

如果只是想集成到自己的项目里，各个功能模块都是独立的 npm 包，按需引用：

和现有库的定位差异

mapgpu 不是现有库的替代品，更像是在补一个细分场景的空白。

MapLibre 和 Leaflet 的生态成熟、文档完善，在中等数据量下是更稳妥的选择。Cesium 在 3D 地球和 3D Tiles 场景下经过大量生产验证，API 也更丰富。mapgpu 目前刚开源，生态几乎为零，API 还在变化，稳定性需要时间沉淀。

它更有可能适合的场景：需要处理大规模实时数据（百万级别的点、线、面），对帧率有明确要求，并且愿意接受早期库的不确定性。

关于许可证：README 说明使用的是 PolyForm Noncommercial License 1.0.0——个人、教育、研究用途免费，商业用途需要单独联系作者授权。在生产环境使用前需要确认这一点。

写在最后

mapgpu 目前还是一个非常早期的项目——2026 年 3 月才公开，14 个 star，文档和 API 都在变化中，没有经过生产环境验证。如果你现在有要上线的 GIS 项目，它还不是合适的选择，MapLibre 或 Cesium 更稳。

但它有另一个值得利用的价值：源码本身是很好的学习材料。

Web 端 GIS 开发想深入原理，往往很难找到足够清晰的参考代码——MapLibre 和 Cesium 的代码库庞大且历史包袱重，新手很难理清脉络。mapgpu 还小，结构相对清晰，而且覆盖了几个在其他地方不容易找到完整实现的主题：

• WebGPU 渲染管线怎么组织地理数据的绘制（@mapgpu/render-webgpu）
• GPU picking 在地图交互场景里怎么实现
• Rust/WASM 模块怎么和 TypeScript 前端配合处理空间计算（@mapgpu/wasm-core）
• 2D/3D 双模式下坐标系和投影变换怎么设计
• 3D Tiles 格式（B3DM、I3DM 等）的解码器怎么写

这些实现思路在浏览器端 GIS 领域都算稀缺，作者把它开源出来，对想了解这个技术方向的人来说，下载代码跑起来看看是有收获的。

https://github.com/mgurbuz-tr/mapgpu (opens in a new tab)