企业官网建设流程全解析

简介：天地图离线地图资源包针对内网或无外网环境下无法直接访问天地图在线服务的问题，提供经过改造的JavaScript与CSS源码，适合Web前端开发、GIS应用集成及网络受限项目中的地图展示需求。压缩包共5个文件，包含4个JS文件与1个CSS文件，体积仅100KB左右；JS文件封装了天地图API调用、本地瓦片加载与坐标转换逻辑，CSS文件则对图层控制、比例尺等界面元素做了样式适配。已有2350人学习下载，足以说明其实用性。通过这份资源，开发者可以快速了解离线地图服务的实现思路，参考URL替换、服务地址指向本地等关键改动，并结合自身内网环境配置服务器地址，为受限网络下的地图应用提供一套可运行、可二次修改的起点。 前一阵给一个政企类的内网项目做地图功能，网络环境严格隔离，外网地图服务一概不能用，业务上又需要直观展示区域分布和点位数据。折腾了一圈，最后回到的路线就是“天地图离线地图”——把天地图的瓦片数据拉到本地，用开源的JS库加载，再用CSS把交互控件和弹窗外观收拢成项目想要的风格。这套东西做下来，最大的体感是：真正的难点不在JS和CSS本身，而在于怎么把数据、坐标系、切片规则这些地基打对。这篇就把整个落地过程从头到尾拆开讲，涵盖方案选型、瓦片处理、代码实现、性能优化和排坑记录，适合正在做WebGIS、内网系统或者国产化适配的开发者参考。

1. 选型思考：离线地图方案其实不止一种

1.1 天地图在线API与离线地图的本质区别

很多人一开始会把“天地图离线地图”理解成“在自己服务器上部署一套天地图API”。这个理解其实有偏差。天地图的在线API本质是一个远程服务：你的页面在用户浏览器里运行，通过外网请求天地图的瓦片服务接口，再用官方JS API把瓦片渲染成地图。这个过程依赖实时访问外网，一旦网络隔离就全部失效。

离线方案则是另一条逻辑：提前把某一坐标系、某一级别范围的所有瓦片图片下载到本地，然后使用通用的WebGIS前端库（比如Leaflet或OpenLayers）去加载本地文件或本地静态服务。这个方案不再依赖天地图官方服务器，也不依赖官方API，只把天地图当作“数据源”使用。

两者从使用目的上就不同：在线API适合快速开发、免运维、但受外网限制；离线方案适合内网环境、数据安全要求高、可完全掌控地图表现。如果你只是做内部系统展示，不需要频繁更新数据，离线方案的性价比会更高。

1.2 前端库选型：为什么我没有自研，也没有用官方API

离线地图的渲染层，社区里成熟可选的有Leaflet、OpenLayers、MapLibre GL，以及天地图官方JS API。我最终选了Leaflet，核心原因有三点：

• 体积小，压缩后不到42KB，对加载性能非常友好。
• 生态成熟，插件丰富，标注、绘制、聚合、测量都有现成方案。
• CSS定制极其灵活，所有控件都能通过覆盖样式轻松改外观，非常适合业务系统需要统一UI风格的场景。

天地图官方API其实只适合在线场景，而且版本迭代频繁，官方一旦改版，你的代码可能需要跟着升级。内网环境一旦部署完毕，最怕的就是这种外部依赖带来的不确定性。OpenLayers当然也很强，它的坐标系处理、投影转换能力更细，但它的体量和学习曲线相对Leaflet要重一些。如果你后续要做大量空间分析、复杂几何编辑，可以换OpenLayers；如果主要做展示、标注、简单交互，Leaflet是更省心的选择。

2. 瓦片数据准备与坐标系处理

2.1 天地图切片规则与常用坐标系

天地图的在线瓦片服务，影像底图一般使用Web墨卡托投影（EPSG:3857），图层切片规则遵循标准XYZ编码，即路径为{z}/{x}/{y}.png，其中z代表缩放级别，x为列号，y为行号。工具箱脚本下载瓦片时，也都是按这套规则去请求的。

这里有一个容易混淆的点：天地图的地理底图（不带影像）有时标注的是CGCS2000或WGS84经纬度坐标，但瓦片服务的空间参考通常已经做了投影转换，实际展示在Web地图上用的是Web墨卡托。也就是说，你下载天地图瓦片，拿到的就是一套预先投影好的全球金字塔图片，前端加载时不需要再做投影转换，只需按XYZ规则挂接。

瓦片行列号的计算逻辑可以简单理解为：

x = floor((lon + 180) / 360 * 2^z) y = floor((1 - ln(tan(lat_rad) + sec(lat_rad)) / π) / 2 * 2^z)

真实项目中不需要手写这个公式，但你一定要理解它，因为后面排查“瓦片错位”“部分级数不显示”时，这些基础知识能帮你快速判断问题来源。

2.2 切片下载与目录整理实操

离线瓦片获取方式大体分两类：一是利用在线地图服务，从天地图官网下载指定范围的瓦片；二是在已有网络环境时，用爬虫脚本切片下载。无论哪种，瓦片数据整理都很关键。

我这次采用的方式是：在可联网的临时环境里，用脚本遍历目标区域的经纬度范围，计算出某一缩放级别下的x、y区间，然后一次请求一张瓦片保存到本地。目录结构保持标准的{root}/{z}/{x}/{y}.png，这样Leaflet的tileLayer可以直接挂载，不需要额外的路径映射。

操作中需要注意存储容量的计算。最普通的估算公式是：总瓦片数 = Σ(2^z)^2 × 面积比例系数。实际项目中，每个z层级的瓦片数量是4的倍数关系：当z增加1，瓦片数量大约是上一级的4倍。所以如果你下载到z=14级，瓦片数量可能已经有几十万张，生产环境务必提前评估磁盘占用和下载耗时。我实测某省会级别的范围，z=10到z=15，总瓦片数大约四十万张，占用空间15GB左右。这个量级放在内网服务器上没有问题，但千万别放到系统盘里，别问我怎么知道的。

3. 核心代码实现：JS加载离线瓦片与CSS定制

3.1 Leaflet加载本地瓦片的完整示例

如果你已经准备好瓦片目录，项目里按静态资源方式部署，比如放在Nginx的html根目录下的tiles文件夹里，前端加载代码可以写得很干净：

// 初始化地图容器，设置中心点和缩放级别 const map = L.map("map", { center: [34.34, 108.94], zoom: 10, minZoom: 5, maxZoom: 15, zoomControl: false, // 先用默认，后面自己加样式 preferCanvas: false, // noWrap: true, // 如果只下载了局部区域，建议打开noWrap防止世界重复平铺 }); // 加载本地瓦片 L.tileLayer("tiles/{z}/{x}/{y}.png", { minZoom: 5, maxZoom: 15, tileSize: 256, className: "tile-layer", // 便于CSS精确控制 keepBuffer: 4, updateWhenIdle: false, }).addTo(map); // 添加一个简单的标记弹窗 const marker = L.marker([34.34, 108.94]).addTo(map); marker.bindPopup("<b>离线天地图测试点</b><br>这个弹窗样式可以用CSS覆盖。");

这里的几个参数很有讲究。tileSize: 256要和你的瓦片实际像素尺寸一致，一般天地图瓦片是256x256。keepBuffer控制视野外的预加载范围，数值越大屏幕外提前加载的瓦片越多，拖拽越流畅，但内存消耗也会增加。updateWhenIdle: false可以避免拖动结束后出现白块闪烁，代价是拖动过程中请求更频繁。

如果你只需要展示某个局部区域，记得打开noWrap: true。否则在地图缩小到一定级别后，Leaflet会把世界地图重复平铺，看起来像是前后左右都是重复的同一种地形，用户会觉得系统有问题。

3.2 CSS定制离线地图的三个关键细节

离线瓦片本身样式固定，但用户交互控件的观感完全可以自定义。CSS定制里最值得注意的有三块：容器尺寸、控件外观、弹窗样式。

容器尺寸是最容易被忽视的。很多项目里地图容器是弹性布局，但父级元素高度为0，结果地图怎么都不显示。建议直接用CSS锁定地图容器：

#map { width: 100%; height: 600px; background: #e0e0e0; z-index: 0; }

背景色也很重要。当你打开页面比较早，或者快速拖动导致瓦片还没加载完时，底图露出的背景就是这里设置的颜色，建议设置成接近影像瓦片亮度的浅灰色或浅绿色，视觉上不会太突兀。

缩放控件的默认样式和很多后台管理系统的风格格格不入。覆盖的时候注意选择器的优先级，可以直接对.leaflet-control-zoom下手：

.leaflet-control-zoom { border: none !important; border-radius: 8px !important; box-shadow: 0 2px 8px rgba(0, 0, 0, 0.15) !important; overflow: hidden; } .leaflet-control-zoom a { width: 36px !important; height: 36px !important; line-height: 36px !important; font-size: 18px !important; color: #333 !important; background: #fff !important; border-bottom: 1px solid #f0f0f0 !important; } .leaflet-control-zoom a:hover { background: #f5f5f5 !important; color: #1890ff !important; }

弹窗同样可以做成卡片样式，把默认的大白块改成圆角、浅阴影、自定义字体的风格。因为Leaflet默认的.leaflet-popup-content-wrapper带圆角和阴影，如果你要做得更精致，需要覆盖它，并连带调整::before箭头：

.leaflet-popup-content-wrapper { border-radius: 12px !important; box-shadow: 0 4px 16px rgba(0, 0, 0, 0.12) !important; padding: 4px 8px; } .leaflet-popup-content { font-size: 13px; line-height: 1.8; margin: 12px 16px !important; }

这里要特别提醒：处理Leaflet样式时尽量统一使用!important或写一个更高优先级的选择器，因为Leaflet自己的CSS文件会在你之后加载，优先级不够时你的样式会被静默覆盖。这个问题的表现就是你写了半天不生效，打开控制台查样式才发现被Leaflet默认样式顶掉了。

4. 进阶功能与性能优化

4.1 坐标拾取与绘制：离线环境下必须本地化

如果你只加载底图，那整个系统最多算个“地图浏览器”。实际项目里往往需要加点位、圈选范围、坐标展示。这就涉及到一系列本地化问题。

天地图在线API里自带坐标拾取、搜索、路网分析能力，但离线环境下这些服务全部不可用。我的做法是：坐标拾取用Map鼠标事件自己实现，只输出经纬度；定位搜索用本地POI数据集做匹配；绘制使用Leaflet的绘图插件。这一层改造并不复杂，关键是别指望离线后天地图API还能帮你做业务逻辑。

map.on("click", function (e) { const latlng = e.latlng; const container = document.getElementById("coordinate"); container.value = `${latlng.lat.toFixed(6)}, ${latlng.lng.toFixed(6)}`; });

坐标精度一般保留6位小数就足够满足厘米级展示了。如果系统要求显示CGCS2000平面坐标，需要在前端做一个动态坐标转换，这就要引入一个转换库或后台计算接口。实际项目中，我更推荐在后端做转坐标，前端只负责展示，逻辑更清晰。

4.2 性能优化：瓦片预加载、地图缓存和静态化部署

离线地图加载慢，通常不是地图库的问题，而是瓦片服务和网络链路的问题。我在优化阶段实测了几个策略：

第一，瓦片合并。把单张256x256的瓦片，按4x4合并成一张1024x1024的大瓦片，然后通过Leaflet的tileSize: 1024加载。理论上请求数减少到原来的1/16，但实际上瓦片服务端处理响应变大，渲染和缓存策略也会变化。实测下来，在低带宽内网环境下请求数减少的收益最明显；带宽充足时，合并不合并差异不大。所以这个方案要看你的内网环境，别盲目跟风。

第二，服务端缓存。如果你的瓦片放在Nginx或CDN后面，开启Gzip和缓存能明显加快重复加载。纯静态瓦片本身是图片，再压缩意义不大，但HTTP缓存策略要设好：

location /tiles/ { add_header Cache-Control "max-age=86400"; access_log off; expires 7d; }

第三，按需加载。不要一次性把所有瓦片都下载到边缘环境，前端按视野范围请求，服务端提前把常用热点区域的瓦片做预生成。地理信息的一个规律是：百分之八十的访问量集中在百分之二十的热点区域。你可以先用热力统计圈出热点范围，对这些范围预生成瓦片存内存，其余范围从磁盘读取。

第四，前端善用preload。如果用户大概率会从A区往B区拖，可以在页面空闲时提前把B区瓦片用Image对象加载一遍：

const img = new Image(); img.src = "tiles/12/1234/5678.png";

这样用户真正拖过去时浏览器已经命中缓存，体验会顺滑很多。

5. 常见问题与排查技巧实录

5.1 瓦片不显示、偏移、样式失效的定位方法

问题1：瓦片加载不出来，控制台看资源请求404。这种情况九成是瓦片路径或文件名大小写不对。天地图瓦片命名方案很多种，有的用{z}/{x}/{y}.png，有的用{z}-{x}-{y}.png，还有优化算法重排过的目录结构。先静态访问一张瓦片的URL，确认能打开再检查代码路径变量。

问题2：所有瓦片都出来了，但整体地图偏移，有的地方还有错位。这种情况通常是坐标系没有对齐。如果你下载的是WGS84地理坐标系的瓦片，但前端初始化时配置成了Web墨卡托，或者经纬度中心点输入错了，就会出现这种偏移现象。解决方式是：先在ArcGIS或QGIS里打开瓦片确认坐标，再统一前端坐标系。

问题3：图层加载正确，但点标记位置和影像对不上。这种情况大概率是投影偏移。天地图在线服务很多图层实际使用CGCS2000坐标系统，直接使用WGS84坐标的GPS数据会有约几十米的系统偏移，需要做坐标转换。

问题4：CSS样式覆盖不了。先看开发者工具，检查元素，看当前命中样式的优先级和来源。不要一上来就加!important，先把加载顺序理清楚。Leaflet默认样式文件在你之后引入时，你又没给自定义CSS加权重，被覆盖就难免了。

这里也顺手整理了一份排查速查表：

5.2 高价值避坑清单

这个项目做完，我个人沉淀了几条经验。第一，瓦片下载务必记录元数据。下载范围、层级、坐标系、时间、瓦片数量这些信息保存成一个json文档，放在瓦片目录同级。否则三个月后你忘了这个目录怎么生成的，就会连实际覆盖范围都无法确认。

第二，慎用强制缓存。内网部署时，如果瓦片长期不变，可以设置长缓存提升体验；但如果瓦片数据会定期更新，长缓存会导致旧图长期驻留在客户端，用户骂娘都找不到原因。这种情况建议设置短缓存或者给瓦片URL加版本号。

第三，容器和DOM层级别乱设置z-index。Leaflet地图默认会创建很多定位元素，如果你在业务页面上给地图容器设置过高的z-index，弹窗、漂浮框可能被盖在底图下面。最好的实践是地图容器z-index保持0，让弹窗、标注等覆盖层使用独立且更高的z-index。

第四，离线环境也别完全放弃线上调试。开发阶段在联网环境调试Leaflet，把整个交互逻辑跑通后，再把瓦片切换成本地路径，这样能大幅减少调试时间。调试过程中注意保持两套环境共用一份代码，只通过环境变量切换瓦片路径，统一性和可维护性都更好。

结尾：一点真实体会

这套天地图离线方案做下来，我最大的感受是：离线地图的核心难点从来不是JS和CSS，而是数据准备和坐标系理解。前端库再怎么选，本质上都是在加载静态瓦片数据，有了数据一切好说，没有数据写再多高级代码都是空中楼阁。所以如果你正在规划类似的内网GIS系统，第一优先级是搞定瓦片数据，再考虑框架和样式。另外建议把瓦片下载脚本保留好，方便后续定期更新数据版本。遇到坐标对不上的问题，先别急着怀疑代码，用GIS工具先把数据源摸清楚，往往能省下半天调试时间。

本文还有配套的精品资源，点击获取