WebGIS 三巨头横评：Leaflet、MapLibre GL JS 与 OpenLayers 怎么选
选型是每个 WebGIS 项目的第一个技术决策，选错方案的代价往往在三个月后才暴露出来。
开篇：没有最好的地图库，只有最匹配的
几乎每个刚开始做 WebGIS 的团队都会卡在同一个问题上：Leaflet、MapLibre GL JS、OpenLayers，我该用哪个？
这三者在 GitHub 上的 star 数都很高，官方文档都很完善，Stack Overflow 上都有充足的讨论。于是选择变成了"看哪篇博客写得更有说服力"。但实际上，真正决定选型的不是 star 数，而是你的数据形态、服务端形态和团队构成。
本文基于三个库的官方文档能力说明和实际工程中的性能数据，给出一套可操作的判断框架。
硬指标对比
先把客观数据摆出来，这些是可以直接测量的：
体积这一项需要放在一起看。Leaflet 的 40KB 在营销落地页上有意义，在一个已经加载了 1MB React 的单页应用里，200KB 与 300KB 的差别并不显著。不要为体积数字本身焦虑，要看它在你实际工程里占的比重。
三个真实的分支场景
场景一：内容站上的几个标记点
如果你的需求是"在文章里放一个地图，标几家门店，点开看地址"，那么 Leaflet 是唯一合理的选择。
它的核心优势是心智负担低。CDN 引一行，L.map()、L.tileLayer()、L.marker() 三行代码就有一个能跑的地图。不需要理解 source、layer、style 的分层概念，不需要处理投影，不需要关心 GPU。
这种场景下引入 MapLibre 或 OpenLayers 是纯粹的自我伤害——你为一个永远不会用到矢量化渲染能力的应用，背上了 160KB 到 260KB 的额外体积和一整套更陡峭的概念。
场景二：真正的"地图产品"
如果你要做的是一个有自定义底图、矢量瓦片、动态样式的地图产品，MapLibre GL JS 是 2026 年的默认答案。
它的杀手锏是样式即产品。整个地图的外观由一份 JSON 样式文档决定——画什么数据、按什么顺序画、怎么画，全部是配置而非代码。这意味着你可以在不触碰一行渲染代码的前提下，把地图从"白天模式"改成"夜间模式"，可以把配色方案交给设计师，让设计直接改 JSON 而不用等前端排期。
配套生态也足够成熟：MapLibre 是 Mapbox GL JS 的开源 fork，迁移基本就是把 mapboxgl 全局替换成 maplibregl；OpenFreeMap 提供免费托管瓦片用于起步。
场景三：需求里出现了 GeoServer、WMS 或非标准投影
这是最容易被忽视、但一旦出现就无法回头的分支。
如果你的数据来自国土、规划、公安等传统 GIS 部门，它很可能是 EPSG:27700（英国国家格网）或者某个 3 度带 / 6 度带投影；服务接口很可能是 WMS 或 WFS-T。这些情况下 OpenLayers 是唯一 sane 的选择。
原因在于坐标投影处理是架构级的。OpenLayers 的坐标转换是内置的、有明确文档的：
const map = new ol.Map({
layers: [
new ol.layer.Tile({ source: new ol.source.OSM() }),
new ol.layer.Vector({
source: new ol.source.Vector({
features: [ new ol.Feature({
geometry: new ol.geom.Point(
ol.proj.fromLonLat([-0.09, 51.505]) // ← 坐标是有投影的
)
}) ]
})
})
],
view: new ol.View({
center: ol.proj.fromLonLat([-0.09, 51.505]),
zoom: 13
})
});注意 ol.proj.fromLonLat 这次调用。OpenLayers 诚实地承认坐标有投影归属，忽略它会导致真实 GIS 项目里难以排查的微妙偏差。Leaflet 把这层隐藏了（通常也能蒙混过关），OpenLayers 把它显式化了（专业用户更偏好这一点）。
OpenLayers 在编辑能力上同样是生产级的。ol/interaction/Draw 和 ol/interaction/Modify 可以让用户画多边形、编辑现有几何。如果你的应用有这个需求，不要重新造轮子。
代价是学习曲线真实存在：API 庞大，source/layer/view/interaction/control 这些概念彼此独立，第一天的生产力会很低，但第二个月之后会很高。
决策树
你的需求是什么？
│
├─ 几个标记点 + 弹窗 ──────────────► Leaflet
│
├─ 矢量瓦片 / 自定义样式 / 3D ───► MapLibre GL JS
│
└─ WMS/WFS · 非标准投影 · 编辑 ──► OpenLayers三问三出口。补充几个常见追问：
Q：已经在用 Mapbox GL JS，想摆脱商业许可？
直接上 MapLibre。它是开源 fork，迁移主要是改名。
Q：React 项目该选哪个包装器？
react-map-gl、react-leaflet、ol-react 都有，但要注意包装器不会让你免除理解图层生命周期和地图事件的责任。React 18 的严格模式下，地图组件的挂载/卸载行为仍然需要你亲自处理。
Q：三者都支持移动端吗？
支持。而且只要配上自托管或尊重隐私的瓦片源，三者都不会默认把你的用户坐标发送到任何云端。
一个务实的建议
不要在这个决策上消耗太多时间。默认选 MapLibre，确有理由时换。
体积压到极致的小场景 → 换 Leaflet
需求里出现了 GeoServer / WMS / 非 Web Mercator 的 PBF → 换 OpenLayers
真到了要迁移的时候你会发现没那么难。它们本质上都是"一个 div 加一组坐标加若干图层"，心智模型是可以迁移的。你的地图不关心是哪个库画的，先把东西做出来。
上线前检查清单
无论选哪个，发布前把这几项过一遍：
[ ] 瓦片地址是否稳定、合法、可访问（注意服务条款是否允许你的使用方式）
[ ] 字体、图标 sprite、样式资源分别来自哪里，是否都可访问
[ ] 数据版权署名是否已按要求展示
[ ] 慢速网络下瓦片加载是否有合理的降级表现
[ ] 瓦片请求失败时是否有兜底提示，而不是白屏
[ ] 关键信息是否有非地图的访问方式（比如列表视图）
最后一条经常被忽略，但它同时是可访问性和可靠性的要求。
参考资料
Leaflet 官方文档 — https://leafletjs.com/docs/
MapLibre GL JS 官方站点 — https://maplibre.org/
MapLibre Style Specification — https://www.maplibre.org/maplibre-style-spec/
OpenLayers 官方文档 — https://openlayers.org/doc/
OpenFreeMap（免费托管瓦片）— https://openfreemap.org/