做GIS项目最怕什么？不是坐标系算错，也不是数据采集漏了，而是辛辛苦苦切出来的地图瓦片，前端加载起来卡到让人自闭。我前几年接了一个数字乡村平台的项目，原始用地数据加起来3.6GB的shapefile，按老办法切成栅格瓦片，全库占了100多GB，发布之后浏览器加载一个县级范围的地图要五六秒，放大缩小一路白屏。当时被逼着研究矢量瓦片，从生成工具选型到部署方案，再到前端渲染调优，把整条链路摸了一遍。最终效果是全库矢量瓦片压缩后不到2GB，同范围加载时间压到1秒以内，还能在前端随时改颜色、改描边粗细，不用重新切图。这篇文章就把我在矢量瓦片生成及部署这条路上踩过的坑、验证过的参数、部署方案和前端渲染细节完整写出来，给做GIS二次开发、WebGIS、三维GIS或者数据可视化的小伙伴一个可以直接复用的参考。
1. 从栅格瓦片转向矢量瓦片：一次被加载性能逼出来的技术选型
先讲清楚一个基本问题：矢量瓦片到底是什么，为什么它能让地图加载快这么多。传统栅格瓦片的思路是把地图按金字塔层级切成一张张PNG或JPEG图片，前端请求哪一级就显示哪一级的图片。这种做法最大的问题是每张图片都已经固定了样式，想换个配色只能重新切图；而且图片体积大、数量多，就算是422系服务器配了缓存，用户第一次打开地图的时候也得等半天。
矢量瓦片则完全不同。它不渲染成图片，而是把几何数据按照层级关系切碎后，用Protocol Buffers编码成二进制格式保存，比较常见的后缀是.pbf。前端拿到的是矢量数据，由MapLibre GL JS或者Mapbox GL JS这类渲染库在浏览器端实时画出来。这样做的好处有三个：一是体积大幅度缩小，同样的地物数据，矢量瓦片的体积往往是栅格瓦片的十分之一甚至更小；二是样式完全由前端控制，底图、配色、描边、标注随时改，不用重新切图；三是分辨率无限适配，不管屏幕是2倍还是3倍像素密度，矢量渲染永远清晰。
我当时愿意花时间把整套链路换掉，还有一个很现实的原因：栅格瓦片更新的成本太高了。业务部门三天两头调整地块边界、修改道路走向，每次数据变了都要重新跑一遍全量切片，慢的时候跑了两天一夜，切出来还要重新同步到服务器。换成矢量瓦片之后，前端不依赖图片，服务端更新了数据文件，用户刷新页面就是最新状态。
不过也要泼一盆冷水，矢量瓦片不是万能的。如果你的业务场景需要非常高的加载并发，或者目标用户普遍使用老的浏览器和低端手机，矢量瓦片在浏览器端的渲染压力会明显大于直接显示图片。这个取舍在第三节和第五节里我会展开讲。
1.1 矢量瓦片的核心优势与适用边界
我简单列过一张对比表，方便团队内部决策的时候用：
| 对比项 | 栅格瓦片 | 矢量瓦片 |
|---|---|---|
| 存储体积 | 大，全国级数据可达数百GB | 小，同范围数据通常可压缩到十分之一 |
| 渲染清晰度 | 固定分辨率，缩放会发虚 | 矢量渲染，无限清晰 |
| 样式定制 | 需重新切图 | 前端样式随意改 |
| 更新成本 | 高，每次数据变更全量重切 | 低，替换数据即可 |
| 渲染依赖 | 任何图片浏览器都可以显示 | 依赖MapLibre/Mapbox等WebGL渲染库 |
| 低端设备性能 | 压力小 | 渲染压力大，需要做细节控制 |
在实际选型的时候，我给团队定了一个简单粗暴的标准：如果是基础底图，比如卫星影像、地形晕渲，继续用栅格瓦片；如果是业务矢量数据，比如地块、道路、POI、建筑物轮廓，优先考虑矢量瓦片。混合使用往往是最合理的方案，两个体系可以同时存在，互不冲突。
1.2 矢量瓦片生成与部署的整体链路
矢量瓦片从原始数据到前端显示，中间要经过五个环节：数据准备、格式转换、切片生成、服务部署、前端渲染。每个环节都有成熟的方案，链路本身不复杂，但细节非常多。数据准备阶段要统一坐标系、清理拓扑错误、精简属性字段；格式转换阶段通常要把Shapefile、GeoJSON或者数据库里的数据统一成GeoJSON序列输入给切片工具；切片生成阶段要根据数据量、精度要求设置金字塔层级和简化参数；部署阶段要考虑服务目录结构、缓存策略和跨域访问；最后前端渲染还要处理样式配置、注记避让和交互性能。
如果把这套链路比作做饭，数据准备就是择菜洗菜，切片工具是锅铲，部署是装盘，前端渲染是上桌。大部分人关注的重点都在锅铲上，但真正的口感和成品率，很大程度取决于前期的菜品处理和后期的火候控制。
2. 生产链路搭建：源数据质控、工具选型与切图方案确定
工欲善其事，必先利其器。矢量瓦片生成环节的工具有不少，但适配不同数据规模和使用场景的差异很大。我用过的方案包括tippecanoe、Mapbox Tiling Service（在线方案）、QGIS原生导出、PostGIS配合Martin服务动态切片，以及ArcGIS平台的切片管线。如果只是小范围试验数据，QGIS的导出功能最省事；如果数据量大、需要定制化参数控制，tippecanoe是绕不开的选择。
2.1 为什么我在生产环境选择tippecanoe
tippecanoe是Mapbox开源的一个命令行切图工具，专门用来把GeoJSON、Shapefile等矢量数据切成矢量瓦片。我选择它有几个非常实际的理由：第一，命令行工具可以放进自动化流程，配合脚本实现定时重切；第二，它对超大数据的处理能力非常强，内存管理做得很成熟，我用它切过几个GB的全省建筑轮廓数据，没崩过；第三，参数设计非常精细，从最低层级到最高层级、简化系数、属性压缩方式都可以精确控制；第四，输出格式灵活，既能导出标准目录，也能导出MBTiles数据包。
相比之下，QGIS的矢量切片导出功能更适合数据量小、临时使用的场景，参数自由度不如tippecanoe。PostGIS配合Martin这种动态切片方案最灵活，但要求源数据存在数据库里，而且并发量大的时候对数据库压力比较大，初期部署成本也更高。ArcGIS的管线强悍但闭源，授权费用和定制化限制让很多中小型项目很难接受。
2.2 源数据质控最容易被忽略的三个细节
做矢量瓦片第一个容易翻车的点，是坐标系。tippecanoe默认要求输入数据是WGS84经纬度坐标，也就是EPSG:4326。很多原始shapefile用的是高斯克吕格投影或者Web墨卡托投影，直接拿给tippecanoe处理，切出来的瓦片位置会偏到完全没法看。所以我在数据准备阶段都会先用GDAL做一次坐标系转换，顺便标准化字段编码。
第二个细节是拓扑清理。原始矢量数据里常见的问题是自相交多边形、重复节点、冗余顶点，这些在ArcGIS或者QGIS里肉眼看着不明显，但切出来的瓦片在前端渲染时容易出现破面、描边错乱。建议在进切片管线之前先用QGIS的矢量几何修复工具，或者PostGIS的ST_MakeValid跑一遍。这一步虽然费时间，但能省掉后面排查渲染bug的大量精力。
第三个细节容易被忽略，就是属性字段精简。很多原始数据表里带了几十个字段，比如地块数据可能有权利人、权属性质、验收日期、备注、内部编号等。但前端真正用到的可能只有三五个字段。tippecanoe切片时会把所有字段都编码进pbf文件里，字段越多瓦片体积越大。我习惯在数据准备阶段就把字段裁剪到前端实际使用的最小集合，把备注这种大文本字段一律丢掉，体积能缩小30%以上。
2.3 多图层数据合并切片的组织方式
真实项目里通常不止一个图层。我拿到过包含建筑物、道路、水系、绿地、POI五个图层的数据，如果每个图层单独切片，前端要请求五套瓦片源，既慢又难以统一管理。tippecanoe支持一次命令输入多个文件，把不同图层数据写进同一个瓦片集，每个数据源通过-l参数指定图层名，前端样式里按图层名去引用就行。
tippecanoe -Z 10 -z 16 -e /data/vector-tiles \ -l building -o /tmp/building.geojson \ -l road -o /tmp/road.geojson \ -l water -o /tmp/water.geojson \ -l green -o /tmp/green.geojson \ -l poi -o /tmp/poi.geojson这种做法的好处是每一级缩放的瓦片只有一个文件，前端一次请求就把当前视口所有图层的数据都拿回来了，省去了多个图层的匹配对齐问题。但要注意，多图层合并后单个瓦片的体积会变大，层级越大的瓦片项目越多，所以参数需要根据实际数据量做调整，这部分我在第三节详细说。
3. tippecanoe 核心参数实测：金字塔层级、简化策略与属性取舍
tippecanoe的参数非常多，官方文档几十页，但真正在生产环境里高频使用的核心参数也就那么十来个。参数设置得当与否，直接决定了瓦片集的质量和体积。先说一个我反复使用的完整命令模板，然后逐项拆解参数含义和踩坑经验。
tippecanoe -e /data/vector-tiles \ -Z 10 -z 16 \ -ps -pf -pk -P -r 1 -S 10 \ -l base \ -o /data/output.geojson \ --drop-densest-as-needed \ --extend-zooms-if-still-dropping \ --no-tile-stats \ --no-tile-size-limit \ --coalesce-densest-as-needed \ --generate-ids注意，生产环境命令建议写成脚本，方便下次重切和参数调整。上面这个命令把最大瓦片体积限制关掉了，对于大区块数据是必要的，但也要小心使用，因为单个瓦片过大会拖慢前端解析速度，具体情况后面讲。
3.1 最大/最小缩放级别这样设置才不会瓦片爆炸
-Z和-z分别指定最低层级和最高层级。最低层级决定全球视角下数据什么时候开始显示，最高层级决定放大到什么程度还有数据。最典型的错误是盲目设置过高的最高层级，比如无脑-z 20。如果原始数据的精度只有1:5000比例尺对应的详细程度，切到20级时几何精度跟不上，数据会被疯狂重复细分，瓦片数量和体积都会爆炸，切图时间从半小时暴涨到几十个小时。
我建议先用一个中间层级测试，比如把原始数据在QGIS里打开，看一下在什么缩放级别下要素细节已经完全呈现，再往上就是重复堆顶点。以建筑轮廓为例，15级基本就能看清街道边线和建筑转角，16级已经足够业务使用，17级往上肉眼很难区分差异。所以项目中我一般设置-z 16，最多-z 17。如果后续确实放大地图需要更细细节，再针对特定区域用-extent参数做局部高精度切片。
设置最低层级也要想清楚，-Z 10表示全球范围开始出现数据。如果层级设太高，用户缩小地图看到的是空白；设太低，低层级瓦片会包含过多要素，单个瓦片体积非常大，前端解码慢。根据我的经验，业务类矢量数据直接从8到10级起步比较合适。
3.2 简化策略：要兼顾视觉平滑和数据体积
原始采集的数据往往有大量冗余顶点，一条看似平滑的河岸线可能有几千个坐标点。tippecanoe默认会对不同层级做不同程度的几何简化，拿捏好简化参数是控制瓦片体积的关键。
-S参数控制几何简化率的阈值，数值越小简化越激进，默认是2.5。我试过-S 5，多边形轮廓会明显失真，转角变成折线；试过-S 1，瓦片体积比默认大了将近一倍。综合下来生产环境我用-S 10配合--drop-densest-as-needed，让工具在到达瓦片大小上限时先丢弃密集区域里的次要要素，这个组合的显示效果和体积最平衡。
另外两个相关的参数经常被混淆：-ps是禁止简化多边形，-pf是禁止简化线串。我通常把-ps和-pf都加上，目的是保留几何的原始精度。很多时候几何被简化后，面积计算、长度量测都会有很小误差，业务上不允许。如果数据源本身顶点过于密集，那你应该在数据预处理阶段做顶点抽稀，而不是依赖切片工具去简化。
3.3 瓦片大小限制：--no-tile-size-limit 到底该不该开
tippecanoe默认会把单个瓦片控制在500KB以内，超过上限就会优先丢弃低重要性要素。对于大多数业务图层这个默认值没问题，但遇到大范围的复杂面状数据，比如大的湖泊、连绵的山体多边形，默认限制会让要素在中低层级直接消失，前端表现为地图上突然缺了一大块。
所以高复杂度数据要加--no-tile-size-limit和-P（允许超出瓦片限制），一是取消大小限制，二是允许超出。但这带来了另一个问题：一个瓦片如果太大，前端下载和解码时间都会增加。瓦片PBF解析是纯CPU密集操作，超过2MB的pbf在普通配置的浏览器上会有明显卡顿感。
我实测过一个包含密集建筑和道路的市中心区域，关闭瓦片大小限制后，16级单个瓦片最大能到4MB，在笔记本上加载动画明显掉帧。最终我的处理方式是：关闭限制，同时把那些体积异常大的图层单独拆分，比如把建筑轮廓按片区裁剪成多块分别切片发布，把单片瓦片控制在1MB以内，这样加载体验能稳定在可接受范围。
3.4 属性保留与中文标注的取舍
pbf文件里属性字段越多，瓦片体积越大，但很多前端样式又必须依赖属性字段做分类渲染。比如地块要按用地性质着色，那就必须保留用地性质字段。我的原则是能用整数ID的绝不用字符串文本，能用短代码的绝不用长文本。状态码、分类编码这些尽量转成数字，前端样式里做数字到颜色的映射，而不是在瓦片里存一排中文说明文字。
中文字段名是一个特别容易被忽视的坑。GeoJSON属性名理论上支持中文，但tippecanoe生成的pbf在前端解析时，MapLibre GL的表达式对中文字段名的兼容性并不好，容易出现样式不生效或者解析异常。我统一在数据准备阶段用ogr2ogr把字段名改成英文，比如“name”改成“name”，“用途”改成“landuse”，“面积”改成“area”，然后前端再通过图层配置显示中文标签。实测这个习惯能减少大量前端调试时间。
4. 瓦片部署与访问优化：静态文件、容器化与缓存体系
瓦片切完之后只是生成了目录或mbtiles文件，要让它真正被前端访问到，还要做好部署。很多人觉得瓦片部署不就是扔到一个静态服务器里吗？实际做起来会发现有不少坑，比如目录层级匹配、跨域配置、缓存策略失灵、并发请求过多导致服务器崩溃。
4.1 mbtiles与标准目录两种输出方式怎么选
tippecanoe支持两种输出方式：-e参数导出标准目录结构，或者-o参数导出mbtiles（一个SQLite数据库文件包）。两种方式各有优劣。
标准目录形式的瓦片结构是 /tiles/{z}/{x}/{y}.pbf，这种结构可以直接用Nginx提供服务，也可以很方便地做CDN缓存。优点是部署简单、单瓦片可独立更新、方便排查问题；缺点是小文件特别多，数量动辄十几万个，同步起来费劲。
mbtiles形式是一个单独的数据包文件，便于传输和备份，可以整体复制到任何一台服务器上直接解包使用。但动态请求mbtiles里的内容需要专门的瓦片服务器，比如Martin、tileserver-gl，这些服务会把mbtiles映射成HTTP接口。相比之下tileserver-gl更像一个完整的瓦片服务网关，自带前端样式调试页面，适合团队内部分发和预览。
我的生产选择是标准目录加Nginx，原因很简单：可以用Nginx直接做gzip静态压缩和缓存策略，不依赖额外的瓦片服务进程，运维成本最低。但是如果你有动态更新瓦片的需求，或者想让多个前端项目共用一套瓦片服务，tileserver-gl是更省事的选择。
4.2 基于Docker部署一套可复用的瓦片服务
为了方便团队复用，我把整套瓦片服务做成了镜像，核心是一个Nginx容器挂载瓦片目录。Dockerfile如下：
FROM nginx:1.27-alpine COPY ./nginx.conf /etc/nginx/conf.d/default.conf COPY ./tiles /usr/share/nginx/html/tiles EXPOSE 80nginx.conf里几个关键配置记得写清楚：开启gzip、配置静态缓存有效期、设置跨域头：
server { listen 80; server_name _; root /usr/share/nginx/html; location /tiles/ { add_header Access-Control-Allow-Origin *; gzip on; gzip_types application/x-protobuf application/vnd.mapbox-vector-tile application/json; gzip_static on; expires 7d; access_log off; } }这里有个细节值得注意：gzip_types里一定要加上application/x-protobuf和application/vnd.mapbox-vector-tile这两个MIME类型，否则Nginx默认不会对pbf文件做gzip压缩。tippecanoe本身不能输出gzip压缩过的pbf，所以前端传输时的压缩完全靠Nginx这一层。我在没有配置gzip的时候测试过，pbf文件直接传输体积是3MB，开启gzip后降到900KB，加载速度提升非常明显。
再补一个跨域配置的坑：很多项目的地图服务和数据API不在同一个域名下，浏览器跨域请求默认被拦截。上面配置里的add_header Access-Control-Allow-Origin *;就是解决这个问题的。但要注意，如果你需要携带Cookie凭证，不能使用通配符，必须写具体域名并加上Access-Control-Allow-Credentials: true。
4.3 增量更新与缓存预热策略
矢量瓦片相对栅格瓦片的优势之一就是增量更新容易。业务数据变化后，我可以只重新切受影响区域的瓦片，然后替换到对应目录。具体操作是：用ogr2ogr按行政区代码过滤出有变化的区域数据，单独跑一次tippecanoe，输出到临时目录，再用rsync同步到正式目录。这样做每次更新的数据量通常在几百MB以内，比起全量重切节省了大量时间。
缓存策略要特别小心。瓦片的文件名是基于坐标生成的哈希值，内容变了文件名并没有变，所以浏览器和CDN的缓存如果不失效，用户看到的还是旧数据。我通常的做法是：Nginx配置expires 7d用于常态缓存，但在做瓦片更新的当天，先把Nginx配置里的过期时间临时改为no-cache，等更新完成后再恢复。如果是大规模更新，更简单的方式是在瓦片URL后面加一个版本号参数，比如https://map.example.com/tiles/{z}/{x}/{y}.pbf?v=20250601，前端一次性切换新版本URL，彻底避免缓存错乱。
考虑性能优化时还有一个小技巧：对最常用的低层级瓦片做预热。全球层级11到13级的瓦片数量少、访问频率高，服务器启动后可以写个脚本主动请求一遍，把这些瓦片预载进系统页缓存，首次加载时延迟从一两秒降到几十毫秒。
5. 前端渲染落地：MapLibre GL 加载、样式调优与常见渲染问题
服务器把瓦片吐出来了，最后一步是前端浏览器里把矢量渲染出来。目前市面上最常用的开源渲染库是MapLibre GL JS，它是Mapbox GL JS的开源分支，API兼容度高，社区活跃。实际项目里我用的是MapLibre GL JS 4.x版本，配合Vue和React都验证过。矢量瓦片的前端调试比栅格瓦片复杂一些，因为牵扯样式配置和渲染性能，单独抽一节讲。
5.1 一个最小可运行的加载示例
先在HTML里引入MapLibre GL JS和样式：
<link rel="stylesheet" href="https://unpkg.com/maplibre-gl@4.7.1/dist/maplibre-gl.css"> <script src="https://unpkg.com/maplibre-gl@4.7.1/dist/maplibre-gl.js"></script>然后加载地图：
const map = new maplibregl.Map({ container: 'map', style: 'https://map.example.com/style.json', center: [116.39, 39.9], zoom: 11, maxZoom: 16 });这里的style.json是整个前端渲染的核心，它定义了三件事：瓦片数据源地址，图层样式（颜色、线宽、透明度），以及文字标注的字体和布局。一个最简单的style.json长这样：
{ "version": 8, "sources": { "my-tiles": { "type": "vector", "tiles": ["https://map.example.com/tiles/{z}/{x}/{y}.pbf"] } }, "layers": [ { "id": "building-fill", "type": "fill", "source": "my-tiles", "source-layer": "building", "paint": { "fill-color": "#d5d5d5", "fill-opacity": 0.8 } } ] }source-layer必须和tippecanoe生成时用-l参数指定的图层名一致，这是最容易出错的地方。我遇到过好几次前端瓦片加载了但地图上没有任何东西，控制台也不报错，折腾半天发现是source-layer名称写错了。
5.2 文字标注注记的避让与编码处理
矢量瓦片做中文注记比栅格瓦片麻烦得多。显示器上的中文字体需要字形数据，MapLibre GL需要加载字体。通常有两种做法：一种是使用内置的Noto Sans CJK字体，通过glyphs接口按需加载；另一种是直接上传一个PBF格式的字体包。第一种方案实现成本低，但字体文件较大，首次加载标注会先空白一下子；第二种方案对字体的加载更高效，但需要提前用工具把ttf字体转成pbf格式。
我生产项目里用的是内置字体加"glyphs": "https://fonts.example.com/{fontstack}/{range}.pbf"这样的配置，字体源用minio或Nginx静态托管。中文注记的碰撞避让是渲染引擎自动处理的，但仍有坑：如果同一个瓦片里标注点太多，MapLibre会按顺序丢弃部分标注，导致某些POI名称一直显示不出来。解决方法是保证瓦片里POI图层数据量不要太大，分类分图层渲染，或者把symbol层中的symbol-placement: point改成line，适配道路名称标注会自然很多。另外还要注意，tippecanoe生成瓦片时，如果多个要素属性里的name字段相同但坐标位置不同，在低层级就会产生大量重复标注，这时要在生成阶段设置--drop-densest-as-needed，不然前端永远显示不全。
5.3 常见渲染bug排查：要素闪烁、图层错位、样式不生效
矢量瓦片渲染阶段最常见的三类问题，我在项目里都遇到过。
第一类：要素在缩放级别切换时闪烁或消失。这通常是因为tippecanoe生成时对某些要素做了drop处理，或者样式里minzoom/maxzoom设置与瓦片层级不匹配。排查方法是打开浏览器的开发工具，切换到Network面板，看某个视口请求了哪些瓦片，再用tileserver-gl的调试页面逐层查看对应级别瓦片里的要素内容。如果瓦片本身有数据，但前端不显示，多半是样式层级问题。
第二类：图层错位，面要素和线要素对不上。最典型的原因是源数据里面要素和线要素来自不同坐标系，或者切图时部分图层被单独处理过。这种问题用眼睛很难看出来，我用QGIS重新投影检查一遍，问题就清楚了。
第三类：样式修改不生效。这往往是缓存问题，style.json被Nginx缓存了。我把style.json的缓存策略设置成no-cache，瓦片数据走强缓存，样式文件每次重新拉取，这样调整颜色和线宽后刷新页面马上能看到效果。一个小配置，省掉了很多“为什么我改了没反应”的沟通成本。
6. 一次真实项目复盘：加载耗时、瓦片体积与流式更新的权衡
前五节讲的是方法和经验，最后用一个真实项目复盘来验证整个链路的效果，也给打算做同类需求的朋友一个直观的参考值。
这个项目是某城市数字乡村一张图，涉及的数据包括一个县范围的地块边界、房屋轮廓、道路中心线、河流水库、村界和几百个POI点。原始数据从GIS数据库导出的GeoJSON加起来大约1.2GB。按我前面说的流程，经过清洗和字段精简后，数据量降到了约700MB。用tippecanoe在16核32GB内存的机器上全量切片，耗时18分钟，输出的瓦片目录总大小约560MB，压缩传输后实际占用约190MB。
前端使用MapLibre GL JS加载，同范围地图首次加载耗时从栅格瓦片方案的5.8秒降到了920毫秒，漫游操作帧率稳定在55fps以上。这个数据对比在项目汇报时非常直观，业务方也很满意。
对比表格：
| 指标 | 原栅格方案 | 现矢量方案 |
|---|---|---|
| 切图耗时 | 约8小时 | 18分钟 |
| 瓦片总容量 | 28GB | 190MB |
| 同范围首次加载 | 5.8秒 | 0.92秒 |
| 地图样式更新 | 重新切图 | 改前端样式JSON |
| 数据更新方式 | 全量重切 | 局部增量同步 |
还有一个很值得说的权衡点：切图时的数据精度级别。最初业务方要求把地块边界细化到20级，我实测切出来瓦片数量暴增了7倍，而且大部分细节在16级之后就肉眼无感了。我最后拿16级瓦片和20级瓦片的对比截图给业务方看，他们自己都分不清差别，于是最终方案用了16级为主、重点区域17级，切图时间和存储空间都很可控。
增量更新的玩法在这个项目里也验证了价值。后来村里调整了两个图斑边界，我只提取了这两个图斑范围内的数据重新切图，涉及瓦片二十多个，前后不到一分钟就完成了更新。放在栅格瓦片时代，就这两个小图斑也得重新跑一遍全量切片，折腾半天。
最后分享一个小技巧。如果你在项目里也被瓦片性能问题困扰，先别急着堆服务器配置，花两天时间把矢量瓦片这套链路跑通，用实际数据对比一下，大概率会有惊喜。顺便说一句，如果你手头还在用ArcGIS 10.2那套老工具链，也可以用ArcGIS Pro自带的矢量切片功能生成类似格式，只是输出参数的把控远没有tippecanoe这么细。无论选哪条技术路线，关键是把生成、部署、渲染这三层都想清楚，这套方法论是通用的。
