地图开发省了10倍成本：PMTiles让矢量瓦片告别服务器租赁

你刚做完一个可视化项目，数据量不大，但为了让地图能正常加载，还是租了台云服务器配瓦片服务。月底看账单：流量费比开发费还高。这种憋屈，PMTiles 这个新选项或许能帮你省掉。

一个文件就是整套地图

传统地图瓦片服务有个固定套路：每个瓦片一个 URL，按 x/y/z 层级组织。后台要么是预切好的文件目录，要么是动态从数据库里捞数据的服务。无论哪种，你都得维护基础设施。

PMTiles 把这个模式拆了。它把整套瓦片塞进一个文件，通过 HTTP 范围请求（range request）直接读取。浏览器要哪块数据，服务器只传对应的字节区间，不用跑任何动态服务。

GL JS v3.21.0 现在原生支持这个协议。代码层面，你只需要改一行 URL：

之前可能是这样：

map.addSource('some-vector-tileset', { type: 'vector', tiles: ['https://somedomain.com/tileset/{z}/{x}/{y}'] });

现在可以直接丢 .pmtiles 文件地址：

map.addSource('terrain-source', { type: 'vector', url: 'https://somedomain.com/tileset.pmtiles' });

该库检测到 .pmtiles 后缀，自动处理背后的范围请求逻辑。对开发者来说，复杂度被埋进了库里。

为什么这个设计能省掉服务器

关键在"静态文件"这四个字。任何能托管静态资源的地方——对象存储、CDN、甚至 GitHub Pages——都能直接 serve 这个文件。不需要数据库，不需要瓦片切割服务，不需要运维监控。

范围请求是 HTTP/1.1 就有的老标准，但 PMTiles 把它用出了新场景。客户端先读取文件头部的索引，把 x/y/z 坐标换算成字节偏移，然后只拉取那一小段数据。渲染层收到的瓦片和传统方式没区别，但传输成本被压到最低。

这对中小数据量的场景特别友好。几 GB 的矢量数据，压缩后一个文件就能带走。更新时也简单：替换文件，刷新 CDN 缓存，完事。

这家公司的算盘

该厂商不是 PMTiles 的发明者。这个格式由 Protomaps 项目开源维护，去年已经在 Leaflet、MapLibre 等库里有支持。这家头部图商现在跟进，说明它想守住"开发者首选地图库"这个位置。

从商业角度看，这对它的托管业务有一定冲击——毕竟用户现在可以完全不碰它的服务器。但更可能的逻辑是：降低入门门槛，把更多人拉进生态，再在高级功能上变现。基础瓦片服务本来就不是高利润业务，工具链的粘性才是护城河。

对开发者来说，多一个选项总是好事。特别是那些数据敏感、想完全掌控托管方案，或者只是嫌云服务器账单太烦的团队。

实际用起来怎么样

官方文档给了一个 USGS 地震数据的示例。加载 4.5MB 的 PMTiles 文件，渲染成圆点图层，代码量和传统矢量源几乎一样。

性能方面，首次加载需要多一次请求：先拉文件头部的索引（通常几十 KB），之后的瓦片请求和常规方案持平。对于频繁缩放、平移的交互场景，这个 overhead 可以忽略。

限制也有。PMTiles 是只读格式，实时数据更新需要重新生成整个文件。动态聚合、服务端过滤这类操作，还是得走传统服务架构。

所以它最适合的场景是：数据相对稳定、追求部署极简、想砍掉服务器成本的项目。比如内部数据可视化、历史数据集展示、或者原型验证阶段。

生态正在对齐这个标准

PMTiles 的支持列表在快速变长。除了刚加入的 GL JS，MapLibre Native、Leaflet、Cesium 都有插件或原生支持。Protomaps 自己还提供了免费的全球基础地图 PMTiles 文件，直接可用。

这意味着格式本身的网络效应在积累。工具链越丰富，开发者越敢押注，反过来推动更多工具接入。对中小团队来说，选一个已经被多家库支持的开放格式，比赌某个厂商的私有方案更安全。