企业官网建设流程全解析

做地图这一行做了快十年，前前后后跟瓦片谈过好几轮“恋爱”，踩过不少坑，也总结出不少经验。矢量瓦片（vector tile）和栅格瓦片（raster tile）这两个词，几乎每个搞GIS、做WebGIS、搞大屏可视化的人都绕不开。你打开任何一个在线地图，底层都是这两种瓦片在默默干活。很多刚入门的朋友跑来问我：到底选哪个？性能差多少？为什么有人说矢量瓦片是未来，可我看到很多项目还在用栅格？

这篇文章我就把这两种瓦片从头到尾掰开揉碎讲一遍，从数据组织方式、渲染原理、体积对比、工具链，到生产环境里的坑和选型建议，一次说清楚。不管是刚接触地图开发的新手，还是已经在项目里被瓦片方案折腾过的老手，应该都能找到点有用的东西。

1. 为什么会有两种瓦片：从地图切图说起

1.1 瓦片是什么，为什么非得切成小块

先回顾一个基础问题：为什么地图非要切成“瓦片”？你想啊，一张覆盖全世界的地图，如果做成一张完整图片，那文件大小能上TB级，别说浏览器加载不动，单是打开本地文件都会卡死。所以主流方案就是“金字塔切片”——把地图按照不同的缩放级别（zoom level）切成无数个固定大小的小方块，每个小方块就是一张瓦片。

瓦片的编号规则通常是 z/x/y，z 是缩放级别，x 和 y 是行列号。Z级别每增加一级，瓦片数量就变成原来的4倍。Z=0 只有1张瓦片，Z=10 就到了大约100万张，Z=18 那就得按亿来算了。这样切换地图时，浏览器只需要按需加载当前视野范围内的几十张瓦片，其他区域等你拖过去再说，体验就顺滑了。

但“切成小方块”这件事，切法不同，得到的瓦片就分成了两大阵营：栅格瓦片和矢量瓦片。

1.2 栅格瓦片：切出来的是一张张“图片”

栅格瓦片本质上是图片。服务端预先用渲染引擎把地图画好，输出成 PNG 或 JPEG 格式的小图，存到磁盘或对象存储上。客户端拿到什么就显示什么，拿到的就是一张已经包含所有颜色、文字、道路线的成品图。

我举个例子，你用过微信发照片吧？发送前微信会先压缩，对方看到的是压缩后的成品。栅格瓦片也是这样，服务端已经把“怎么渲染”这件事做完了，客户端只负责“展示”这一个动作，没有任何二次加工空间。

栅格瓦片最典型的就是影像底图，比如卫星影像、航拍图，还有那些带精细纹理的电子地图。只要数据本身是“连续面状信息”的，栅格几乎是无脑首选。

1.3 矢量瓦片：切出来的是“数据包”

矢量瓦片就完全不一样了。它切的不是图片，而是几何数据。每一块瓦片里装的是道路、河流、建筑、POI点这些要素的坐标信息，用高效二进制编码（常见是 Protocol Buffers 的 .pbf 格式）压缩起来。客户端拿到这个数据包后，再根据当前视角用 GPU 实时把道路、文字、图块画出来。

还是拿微信照片打比方，矢量瓦片就像是你发给对方一个 PSD 源文件，对方拿到之后可以自己调色、改字、加滤镜。你看到的样式完全取决于客户端怎么“渲染”这个源文件。

所以矢量瓦片有一个栅格瓦片比不了的绝活：同一套数据源，可以实时切换不同的主题样式。白天模式、夜间模式、深色大屏模式、色盲友好模式，切换样式只是一行代码的事，根本不用重新切图。这就是为什么现在的三维城市、大屏可视化、实时路况这些场景越来越倾向于用矢量瓦片。

你可能会问，那是不是矢量瓦片全面碾压栅格？还真不是。接下来我把各个维度拆开对比，你就知道它们各自的地盘在哪了。

2. 数据量对比：为什么矢量瓦片能小上百倍

2.1 我实测过的一组体积数据

先说我实际生产环境里遇到的一组数。一个中等省份的矢量路网数据，用 Mapbox 的矢量切片规范切到 Z=14 级别，最终生成的瓦片包大约只有 200 到 300MB；但同样范围、同样级别的栅格瓦片，如果包含道路、注记、POI 图标全要素渲染，体积直接飙到 30 到 50GB。差了两个数量级。

全球范围的对比更夸张。公开数据里，OpenMapTiles 的全球矢量切片包（到 Z=14 左右）大约 50 到 80GB，而同等覆盖范围的栅格底图，放大到能看清街道级别，怎么也得几个 TB 起步。所以那些在线地图服务商，绝大多数底层都是矢量切片方案，就是因为他们扛不住栅格瓦片的存储和带宽成本。

2.2 为什么体积差这么多

栅格瓦片是“画好了再切”。每一张瓦片都包含完整的视觉信息：背景颜色、道路线宽、文字阴影、图标纹理，这些一旦渲染成图片就得全部存下来。而且不同缩放级别需要重新画、重新切，每个级别都是独立的一套完整图片，所以瓦片集合的体积是随级别增加呈指数级膨胀的。

更关键的是，栅格瓦片里绝大多数像素都是“无信息”的。一张 256x256 的底图瓦片，可能 80% 的区域都是空白的背景色，但 PNG 压缩算法照样要为这些空白像素付费。就算优化到极致，也逃不开“图片存了多少像素就要花多少存储”这个物理定律。

矢量瓦片则完全不同。它存的是“坐标点串”，像一个点两个点一条线，占用的字节数只跟要素的几何复杂度有关，跟你在屏幕上画多大、用多粗的线、什么颜色完全没有关系。一条公路在 Z=10 和 Z=16 级别下，几何数据可能都有，但描述它的坐标点数量基本没变（顶多在不同级别做了简化），所以整体数据量增长远比栅格慢。

2.3 矢量瓦片的数据简化技术

矢量瓦片之所以能做到这么小，还靠一个关键技术：几何简化（simplification）和量化压缩。

几何简化，就是当缩放级别低的时候，删除那些在屏幕上根本看不清的微小弯折。比如一条山路在 Z=8 级别显示时，可能只需要 20 个顶点就能画出来；到了 Z=14 级别道路的弯道清晰可见，才需要 200 个顶点。Mapbox Vector Tile 规范里有个 quantization（量化）参数，默认把瓦片内的坐标映射到一个 4096x4096 的网格上，用一个 14 位整数表示坐标，比直接用浮点数节省一半空间，然后再用 Protocol Buffers 做一次紧凑编码。

还有一个容易忽略的点：矢量瓦片只在需要的级别存需要的要素。比如某些小字号的POI点，在低级别直接就不存了，只在高级别才出现。而栅格瓦片呢？服务端渲染的时候虽然也能控制哪些要素显示，但画出来的图片里那些看不见的要素并不会帮你省像素。

注意：矢量瓦片体积小是相对“全要素渲染的栅格瓦片”而言的。如果你把栅格瓦片做成只含背景和道路的简化底图，不做任何注记，体积也能压得很低。所以比较时要对等比较，别拿“全要素栅格”和“极简矢量”比，那不公平。

3. 渲染方式与表现力：谁更灵活，谁更省心

3.1 栅格瓦片：服务端渲染，客户端无脑显示

栅格瓦片的最大优点是“所见即所得”。因为渲染发生在服务端，用什么字体、什么颜色、什么线宽都是提前固定好的，到了客户端就是一张图，不存在跨平台渲染不一致的问题。

这个特性在做离线地图、地质图、气象图这类对色彩准确性要求极高的场景时特别重要。比如土壤类型图、地质岩性图，那些颜色都是行业标准规定的，用户拿着图纸对比屏幕，色差一点都会被投诉。这类需求用栅格瓦片绝对不会出错，因为每个用户看到的都是同一张图片。

栅格瓦片的缺点也来自这里：样式完全锁死。你想换一种配色，必须回到服务端重新渲染、重新切图、重新部署，一次全量切片可能跑好几天。而且每个样式都要维护一套瓦片，如果有多套样式（日间/夜间/季节变换），存储成本直接翻倍。

3.2 矢量瓦片：客户端实时绘制，样式自由发挥

矢量瓦片把渲染压力转移到了客户端。浏览器的 WebGL 或移动端的图形 API 拿到坐标数据后，实时生成每个像素。这意味着你可以在用户交互的瞬间改变样式：鼠标划过道路高亮、白天自动切浅色主题、晚上自动切深色主题，都是毫秒级响应。

做智慧城市大屏的时候，我经常要在一个大屏上同时展示：基础道路、实时路况、地铁线路、POI 标注、建筑轮廓。这几个图层如果全用栅格瓦片，我得准备五套瓦片，切换图层就是切换底图，视觉上有割裂感。矢量瓦片可以同时加载一个基础底图，剩下的路况、地铁、POI 都是动态叠加的数据层，颜色、透明度、标注避让全部实时计算，效果是栅格方案做不到的。

不过灵活是有代价的。客户端渲染意味着字库、字体渲染方式不同，会导致跨设备显示效果有细微差异。某个字体在你开发机上显示刚刚好，在用户手机上就可能出现文字重叠或被截断。这类问题在低端安卓机上尤其明显，做项目时一定要提前测试。

3.3 三维场景下的碾压级优势

还有一个栅格瓦片完全没办法比的场景：三维地图（3D Tiles / 倾斜摄影 + 矢量叠加）。三维场景里相机可以倾斜、旋转，栅格瓦片只能贴在平面上当“贴图”，一但视角倾斜，文字和图标就会被拉伸变形，完全没有体验可言。矢量瓦片因为是矢量数据，配合三维渲染引擎可以做到文字始终面向相机（billboard效果）、建筑按高度拉伸、道路随地形起伏贴合，这些动效在智慧园区、数字孪生项目里是标配。

我做过一个城市级的三维展示项目，底图就是用矢量瓦片生成的建筑白模，再叠加实时业务数据。客户看到后说“这比之前那张静态平面图高级太多了”，其实本质差别就是数据从“图片”升级成了“活的几何”。

4. 加载性能与体验：传输、解码、渲染的博弈

4.1 网络传输：矢量瓦片更轻，但首帧不一定更快

单论网络传输，矢量瓦片胜出。一个 256x256 的栅格瓦片，就算简单底图也有 30 到 100KB；矢量瓦片同样范围可能只有 10 到 30KB。加载同样一片视野区域，矢量瓦片少传一半以上的数据，在移动网络下体验差别很明显。

但这里有个反直觉的点：首屏渲染速度，栅格瓦片反而可能更快。栅格瓦片拿到图直接贴上屏幕，不需要解析几何、不需要计算样式，浏览器几毫秒就能画出来。矢量瓦片拿到 .pbf 文件后，要先解码坐标数据、构建渲染指令，再提交给 GPU 绘制，首帧耗时通常比栅格多几十到一百多毫秒。如果你的用户网络特别慢，且设备又很老旧，栅格瓦片反而感觉“更跟手”。

所以做移动端低端机适配项目时，我往往会采用“栅格瓦片出底图”的稳妥方案，确保每个用户都能流畅看到图。而做高端展示、大屏、Web端可视化项目，优先用矢量瓦片，反正电脑和旗舰手机的 GPU 渲染能力完全罩得住。

4.2 客户端设备适配：老手机最怕矢量瓦片

我在一个政企项目里测过一批老旧的国产平板，大概五六年前的配置，WebGL 性能很弱。同样的地图区域，栅格瓦片加载流畅，矢量瓦片一缩放就掉帧，文字重绘还会闪。原因很简单：栅格瓦片把所有渲染工作都丢给了服务端，客户端只做一次图片贴图；矢量瓦片把渲染压力分摊给了用户的 CPU 和 GPU，设备太老就扛不住。

更麻烦的是，部分老设备对 WebGL 的支持不完整，矢量渲染会出现奇怪的图形撕裂。遇到这种情况，要么放弃矢量方案换回栅格，要么给老设备单独准备栅格瓦片，做“双轨降级”。这个属于架构层面的取舍，得在项目初期就评估清楚，别等上线了才发现问题。

4.3 瓦片更新与实时性：矢量瓦片能按需更新，栅格得全量重切

数据更新这块，两者差距也巨大。栅格瓦片只要源数据有任何变化，就得重新渲染，而且因为瓦片之间存在样式连续性，通常需要把影响范围内的所有级别全部重切，一次更新动辄几小时甚至几天。矢量瓦片就灵活多了：源数据变化后，只需要重新生成受影响的那一层数据，旧的瓦片还能继续用，某些方案甚至支持局部瓦片更新。

还有一个更高级的玩法：矢量瓦片可以和前端数据流打通。比如实时路况数据不走瓦片，而是通过接口下发给客户端，客户端再覆盖在矢量瓦片上。但栅格瓦片想做到实时更新，就必须持续重切图片，成本高得多。

所以如果你做的是交通调度、物流追踪、应急指挥这类数据变化频繁的系统，矢量瓦片几乎是唯一合理的选择。底图保持静态，业务数据动态覆盖，成本和体验都能兼顾。

5. 工具链与开发上手：从切图到上线的全流程对比

5.1 栅格瓦片的常用工具链

做栅格瓦片，工具选择比较成熟，门槛相对低。

• QGIS：免费开源，自带切片导出功能，适合做小范围、简单样式的瓦片。操作界面友好，新手一天就能上手。
• MapTiler Desktop：商业软件，但桌面版有免费额度。能把各种格式的GIS数据转成瓦片，内置样式模板很多，出图效果好，适合快速出成品底图。
• ArcGIS Pro：老牌商业GIS平台，切片能力很稳，适合已有 ArcGIS 生态的企业团队。
• GDAL2Tiles：命令行工具，脚本化批量处理神器，适合CI/CD流程里自动化出瓦片包。

栅格瓦片的输出格式就是一堆图片文件，按照 z/x/y 的目录结构摆放。也可以打包成 .mbtiles（SQLite 数据库格式），部署时再通过瓦片服务把里面的图片读出来。后端服务器上用 Nginx 直接 serve 静态文件，或者用 MapProxy、GeoServer 这类瓦片服务中间件，都很方便。

5.2 矢量瓦片的常用工具链

矢量瓦片工具链相对新一些，但生态也已经比较成熟了。

• tippecanoe：Mapbox 开源的矢量瓦片切片工具，命令一行搞定：tippecanoe -o output.mbtiles input.geojson。它对数据做了很多优化，比如按要素密度分级、自动简化几何、丢弃看不到的细节，生成的瓦片体积非常小。我用它切过一个全国路网数据，输出简直让人惊喜。
• Mapbox Studio / MapLibre Studio：可视化样式编辑器，可以导入矢量瓦片元数据，拖拽式设计配色、文字、图标。MapLibre Studio 是开源替代品，适合不能使用 Mapbox 商业服务的团队。
• OpenMapTiles：开源的企业级地图方案，提供了从 OpenStreetMap 数据到矢量瓦片的完整处理管道。还提供可以免费下载的全球瓦片包，省去自己切图的功夫。
• PostGIS + 自研切片：如果你有特殊需求，比如要把业务数据和基础地图一起切片，可以用 PostGIS 做空间运算，再写脚本生成矢量瓦片。这种方案学习成本高，但自由度最大。

矢量瓦片前端渲染库，主要有 MapLibre GL JS（开源，兼容 Mapbox GL 规范）、Mapbox GL JS（商业授权）、OpenLayers（近几年加入了对矢量瓦片的支持）、CesiumJS（三维场景下用矢量瓦片）。其中 MapLibre GL JS 是目前我比较推荐的开源选择，从 Mapbox GL JS 分叉而来，API 几乎一致，迁移成本低。

5.3 一条我觉得稳的全流程路线

这些年我比较推荐的路线是：用 tippecanoe 把数据切成 .mbtiles 格式的矢量瓦片包，部署时再用 Martin（一个轻量级瓦片服务器，Rust 写的，性能很好）把 .mbtiles 直接发布成 HTTP 服务，前端用 MapLibre GL JS 加载并定义样式。

这条链路全开源、无版权坑、性能也完全够用。

我实际测试过，一个 40GB 的路网数据，tippecanoe 切片大概跑了 20 分钟，最后生成的 .mbtiles 只有 1.2GB。Martin 发布后，打开页面首屏加载速度基本在 1 秒以内（本地局域网环境）。相比之前用 GeoServer 发布栅格瓦片，等待时间缩短了非常多。

6. 常见问题排查与避坑经验

6.1 矢量瓦片常见问题速查

6.2 栅格瓦片常见问题速查

6.3 我踩过的几个典型坑

先说一个特别坑的事。有一次做一个全国范围的可视化项目，我图方便，直接下载了某个第三方平台的全球栅格瓦片包，部署到内网之后发现部分地区的文字和边界有严重偏移。排查到最后才发现是投影坐标系不对——平台默认用了 Web墨卡托的投影规则，而我内网的系统里用了经纬度直投的方式。这里提醒一句：瓦片从一开始就要统一投影标准，否则后期会非常多坑。

再说矢量瓦片的问题。有一次前端同事那边报告，说缩放地图时文字一直跳动，看着特别难受。我排查了很久，最后发现是样式文件里的文字字段没开启碰撞检测（collision detection），导致同一个POI在相邻级别里重复渲染，前一个还没完全消失，后一个就出现了。解决办法是把样式里的 symbol-placement 从 point 改成 line-center，或者打开 allow-overlap 的相反开关，文字才稳定下来。

还有一个容易踩的坑是矢量瓦片的“密度陷阱”。某些区域POI特别密集，切成矢量瓦片后单块数据可能大到几百KB，反而比栅格瓦片还大。这时候必须在切片之前做数据抽稀，按照不同级别控制要素数量上限。tippecanoe 的 -r1（强制最低级别密度）和 -B 参数就是干这个用的。

6.4 选型决策：到底该用哪个

最后聊一下项目选型，这也是我收到私信最多的一个问题。没有万能的答案，但有一些判断标准可以参考：

• 如果你做的是标准电子地图、导航地图、类似在线地图的产品，优先考虑矢量瓦片。体积小、更新灵活、样式自由，优势非常明显。
• 如果你做的是影像地图、扫描地图、地形图、地质图这类颜色就是信息核心的场景，用栅格瓦片。不仅省事，而且能保证显示效果和原图完全一致。
• 如果你的用户里存在大量老旧设备（比如政企项目的存量平板），优先用栅格瓦片，或者做双轨降级方案，别让渲染性能拖垮体验。
• 如果项目周期很紧、前期没有专职GIS工程师，栅格瓦片上手更快，因为工具成熟、踩坑少。
• 如果项目要做长期运营，数据会持续更新，那就尽早切换到矢量瓦片，因为栅格瓦片的更新时间成本会越来越让人崩溃。

我个人在实际操作里的体会是：大型项目基本都会采用“矢量底图 + 栅格影像”的混合方案。基础道路和注记用矢量瓦片，卫星影像和业务底图用栅格瓦片。两者配合，既能享受矢量瓦片的轻量和灵活，又能保住影像的真实感，这才是绝大多数生产环境的真实形态。

最后的最后再分享一个小技巧：不管用哪种瓦片，上线前一定做一次“弱网 + 低端机”双体检。Chrome 开发者工具里把网络切成 Slow 3G，再开一台两年前的安卓真机，跑一遍核心路径。你会发现很多在开发机上感觉不出来的问题，在这个组合下全暴露了。这些问题宁可上线前解决，别等客户截图发群里再改。