企业官网建设流程全解析

简介：面向需要实现地图下钻场景的Web前端开发者，这份资源围绕ECharts全国省市三级地图联动展开，解决从全国概览到省份、再到城市逐级点击下钻的交互需求。内容覆盖三级地图JSON数据的组织方式、ECharts地图实例的series配置、click事件监听与动态数据绑定，还涉及tooltip悬浮提示、itemStyle颜色渲染及响应式适配等体验优化，适合具备一定JavaScript基础、希望快速上手地理数据可视化的读者。压缩包整体约3.9MB，内容以地图JSON数据与ECharts相关代码为主，便于结合项目直接参考。目前已有1696人学习浏览，可参考性经过验证。通过对照资料中的实现思路，可以理清多级地图切换时的数据加载流程，掌握地图联动功能的调试要点，减少踩坑，直接复用于业务系统中的区域数据展示场景。 去年年底我帮朋友调一个销售数据大屏，需求乍一看特别简单：全国地图上展示各省销售额，点击某个省下钻到该省的城市分布，再点击城市还能看到区县数据。当时我心想，ECharts地图渲染这么成熟，这功能不是分分钟的事？结果真动手才发现，官方示例里地图基本都是静态展示，全国到省、省到市这种多级下钻联动，从一个数据源到另一个数据源的切换，并没有一个开箱即用的完整方案。网上搜到的代码又大多是四五年前的版本，API早变了。这篇文章就把我从零做“全国→省→市”三级地图联动的完整过程写出来，覆盖GeoJSON数据获取、地图注册、点击下钻、返回上一级、市级数据标记和性能优化，适合正在做数据大屏、后台管理系统的前端同学参考。

1. 地图数据准备：比写联动逻辑更先一步的硬功夫

1.1 GeoJSON从哪里来

ECharts本身不提供地图数据，它只负责把GeoJSON渲染成可交互的地图。所以第一步是解决“数据源”问题。目前国内用得最多的免费方案是阿里云DataV的GeoJSON接口，稳定性不错，而且直接按区域编码（adcode）组织，非常契合多级下钻场景。

基础规则是这样的：

也就是说，只要知道区域的adcode，就能拿到它的边界数据，这为三级甚至四级联动打好了基础。还有一种做法是直接用fetch动态请求这些接口，但我个人强烈建议：在构建阶段把这些JSON下载到本地静态资源目录。理由很现实——第三方接口的输出大小不受你控制，运行时请求如果服务抖动，用户大屏上直接白一块；再说跨域、网络延迟都是变数，生产环境不给自己留这种隐患。下载下来之后按/map/100000.json、/map/320000.json这样组织目录，后续联动只是拼路径的问题。

1.2 _full版本与精简版的取舍

DataV接口里带_full后缀的GeoJSON，包含当前区域以及下一级所有子区域的边界。比如320000_full.json里既有江苏省的轮廓，也有13个地级市的轮廓，这就是省到市联动时直接能用的数据。

但精度高是有代价的。全国地图如果用100000_full.json，文件体积可能达到几兆，首次渲染会有明显卡顿；不带_full的版本只有当前级别的边界，全国地图只有34个省级行政区的轮廓，渲染速度快得多。我的实践是：全国视口用不带_full的100000.json，下钻省级时再加载320000_full.json，既能保留地图细节，又不拖慢首屏。

如果对体积还是不满意，可以用mapshaper这类工具对GeoJSON做简化压缩，把坐标精度从6位降到3位、删除不需要的属性字段，文件能缩小百分之六七十。大屏上显示时视觉差异几乎看不出来，加载速度却能提升一截。

1.3 adcode与名称的映射关系

下钻的关键一步是点击省份后要去加载对应省份的GeoJSON。怎么知道点击的是哪个省？ECharts的点击回调会返回params.name，这是GeoJSON里properties.name的值，而我们需要的是adcode。两种办法：一是直接从params.event对应的地理信息里去拿，但在某些版本和场景下并不稳定；二是维护一张name -> adcode的映射表。

我的做法是一开始就从GeoJSON里把这份映射读出来：

function buildAdcodeMap(geoJson) { const map = {}; geoJson.features.forEach(f => { map[f.properties.name] = String(f.properties.adcode); }); return map; }

这样下钻时只需要const adcode = adcodeMap[params.name]，逻辑简单直接。唯一要注意的是GeoJSON里的name字段可能和业务数据里的名称不完全一致，少数地方有简称、全称的差异，真遇到就在映射表里手工补几个别名，比改数据源省事。

2. 首次下钻：从全国到省份的联动实现

2.1 先搭一个能跑的基础配置

地图联动本质上是“替换地图数据 + 替换业务数据”两个动作的叠加。我先给出一个完整的基础配置，后面所有联动逻辑都围绕它展开：

import * as echarts from 'echarts'; const chart = echarts.init(document.getElementById('mapContainer')); function buildMapOption(mapName, data, visualPieces) { return { tooltip: { trigger: 'item', formatter: params => `${params.name}<br/>销售额：${params.value ?? '暂无数据'}` }, visualMap: { type: 'piecewise', pieces: visualPieces, left: 20, bottom: 20 }, series: [{ name: '销售额', type: 'map', map: mapName, roam: true, label: { show: true, fontSize: 10 }, data: data.map(item => ({ name: item.name, value: item.value })) }] }; }

用visualMap做颜色分级可以让数据一眼看出高低，默认的连续型分段有时不符合业务需求，比如产品要求必须分9段，那就在pieces里写死每段的区间：

const pieces = [ { min: 10000, label: '10万以上' }, { min: 5000, max: 9999, label: '5000-1万' }, // ...按照需求逐段定义 ];

注意pieces里多个区间不要重叠，min和max的边界要仔细核对，不然会出现某个值被两个区间同时命中的情况，表现就是图例和图块颜色对不上。这种自定义分段写法也完全可以满足“9段图变10段图”的定制需求，只要把区间数组增删一项就行。

2.2 点击事件：避免重复绑定的经典坑

下钻的核心是监听地图点击事件。第一次写的时候很容易犯一个错误：每次下钻都调用一次chart.on('click', handler)，结果就是事件越积越多，点击一次触发三次下钻，视图来回跳。

正确做法是把事件绑定放在初始化之后，只绑一次，在回调内部根据当前状态决定下一步动作：

chart.on('click', async params => { if (state.currentLevel === 'country') { const adcode = adcodeMap[params.name]; if (!adcode) return; await drillDown('province', adcode); } else if (state.currentLevel === 'province') { const adcode = cityAdcodeMap[params.name]; if (!adcode) return; await drillDown('city', adcode); } });

这样事件永远只有一个，状态流转完全由state控制，既避免了重复绑定，也把两级下钻的逻辑收拢在同一处，后续要改成三级四级都只是在if链里加分支。

2.3 省份下钻：注册GeoJSON并替换series

从全国切到省份，要做的事有两件：用省份边界重新注册地图，再用setOption替换整个配置。具体代码：

async function drillDown(level, adcode) { const geoJson = await loadMapJson(adcode); // 使用adcode作为注册名，避免不同层级的同名冲突 echarts.registerMap(`area_${adcode}`, geoJson); // 拉取当前层级的业务数据 const data = await fetchBusinessData(adcode, level); const newOption = buildMapOption(`area_${adcode}`, data, getPiecesForLevel(level)); chart.setOption(newOption, true); // 更新状态 state.levelStack.push({ level: state.currentLevel, adcode: state.currentAdcode }); state.currentLevel = level; state.currentAdcode = adcode; }

这里有几个细节要说明。setOption的第二个参数我传了true，这是notMerge模式，表示丢弃之前的配置重新渲染。如果不传，ECharts会尝试合并新旧数据，全国地图的旧series可能会残留，出现两个地图叠在一起的怪象。地图注册名用area_${adcode}而不是直接叫省份名，是因为万一后续要缓存的场景变多，同名的重复注册会互相覆盖，用唯一编码更安全。

2.4 下钻后中心和缩放比例的调整

还有一个容易被忽略的点：从全国切换到省份后，如果不对视口做处理，地图仍然停留在全国视图的center和zoom，省份会缩在屏幕一角。我一般根据GeoJSON计算区域的中心点和合适的缩放级别：

function calcView(geoJson) { // 遍历features里的坐标，计算外包矩形 // center取矩形的中心，zoom根据矩形的长宽比估算 return { center, zoom }; }

ECharts的series-map里可以直接配置center和zoom，下钻之后把这两个值带上，就能让地图自动平移到当前省份的视野中心，而不是停在角落里让用户手动缩放。这个体验细节在给客户演示时特别加分，第一次demo就是因为没加这个，客户以为地图卡死了。

3. 省级到市级：把联动收拢成统一的状态机

3.1 抽一层通用的loadMap

实现了全国到省之后，省到市几乎是同一套逻辑：加载GeoJSON、注册地图、设置center和zoom、渲染数据、更新状态。所以我直接抽了一个通用方法，省的重复代码：

async function loadMapByCode(adcode, options = {}) { const geoJson = await loadMapJson(adcode); echarts.registerMap(`area_${adcode}`, geoJson); chart.setOption(buildMapOption(`area_${adcode}`, options.data || [], options.pieces), true); if (options.center && options.zoom) { // 通过setOption里的geo或series配置更新视口 } // 更新当前选中的区域信息，用于面包屑展示 return geoJson; }

这样不管是江苏下钻到南京，还是浙江下钻到杭州，都只是调用loadMapByCode(320100)还是loadMapByCode(330100)的区别。至于某省有哪些城市，可以从320000_full.json里解析出来，也可以让后端返回“省份+城市列表”的接口，然后前端依次请求每个城市的边界数据。

实际项目中我发现，让后端直接返回“当前层级的所有区域及其销售额”是最省事的。前端只负责渲染，不用关心某个省到底有多少个市、这些市叫什么名字，因为城市名单就在GeoJSON的features数组里。

3.2 给某些市标记数量：散点叠加是最优解

热搜词里有一条“echarts地图怎么给某些市标记数量”，这个需求在市级联动后特别常见。实现方案有两种：改label.formatter，或者在series里再加一个scatter类型。

如果只是把数量显示在区域名称旁边，用label.formatter就够了：

label: { show: true, formatter: params => { const item = data.find(d => d.name === params.name); return item ? `${params.name}\n${item.value}` : params.name; } }

但如果数量不止一个维度，比如要同时展示“销售额”和“门店数”，或者想用气泡大小表示某个指标的相对大小，叠加scatter是更好用的方案。它相当于在map之上再渲染一层点，位置由经纬度决定，数据格式是[lng, lat, value]：

series: [ { type: 'map', map: `area_${adcode}` }, { type: 'scatter', coordinateSystem: 'geo', data: scatterData, // [{ name: '南京', value: [118.78, 32.04, 200] }] symbolSize: val => Math.sqrt(val[2]) * 2, label: { show: true, formatter: params => `${params.name}: ${params.value[2]}` } } ]

需要注意scatter要和geo组件配合使用，如果直接放在series数组里而没有额外的geo配置，有些版本会渲染不出来。另一个坑是scatterData的经纬度坐标需要保证在边界数据范围内，否则点会飘到地图外面去。我一般用城市中心点坐标，十几二十个城市的数据量，性能完全没问题。

3.3 业务数据如何跟着地图联动

很多时候下钻不光是换底图，还要把该省各市的销售额重新拉一遍。这就需要数据接口在设计时就预留“区域编码”参数。我常用的接口格式：

/api/sales?areaCode=320000&level=city

返回的结果就是江苏省内各个城市的销售额集合。areaCode变了，返回的数据也就跟着变；loadMapByCode负责换底图，接口负责换数据，两者同步更新。如果在代码里先改图后拉数据，会出现一个短暂的空窗期——地图已经是南京了，数据还是全国的。所以我在实际封装时用了Promise.all：

const [geoJson, businessData] = await Promise.all([ loadMapJson(adcode), fetchBusinessData(adcode, level) ]);

两个请求并行，等全部返回后再一次性渲染，避免画面闪烁和数据错位。

3.4 状态栈：记住用户是从哪来的

三级联动必须维护一个“来路”信息，否则返回功能没法实现。我用一个极简的状态对象：

const state = { currentLevel: 'country', // country / province / city currentAdcode: '100000', stack: [] // [{ level: 'country', adcode: '100000' }, ...] };

每次成功下钻，就把当前视图压入栈中，再更新currentLevel和currentAdcode。返回就是出栈的过程。这个栈同时还可以用来做面包屑导航，比如“全国 / 江苏省 / 南京市”，每一级都可以点击跳转，体验比单纯一个返回按钮好得多。实际做下来，这套状态机只用了不到一百行代码，联动逻辑却清晰了很多。

4. 返回上一级：容易被忽略的stepBack细节

4.1 返回逻辑的最小实现

返回函数和drillDown是镜像操作：

async function stepBack() { if (state.stack.length === 0) return; const prev = state.stack.pop(); const prevGeoJson = await loadMapJson(prev.adcode); echarts.registerMap(`area_${prev.adcode}`, prevGeoJson); // 同样要拉取上一级的数据并渲染 const data = await fetchBusinessData(prev.adcode, prev.level); chart.setOption(buildMapOption(`area_${prev.adcode}`, data), true); state.currentLevel = prev.level; state.currentAdcode = prev.adcode; }

如果是通过面包屑直接跳转到“全国”，那就不是出栈，而是清空栈然后重新加载全国数据。边界情况一定要处理：栈为空时说明已经在最顶层，此时返回按钮应该置灰或者直接不显示。

4.2 快速点击下的异步竞态

这是我实际踩过最深的坑。下钻和返回都是异步操作，如果用户在加载过程中连续点击，就可能发生“先请求南京，再请求江苏，结果南京的响应比江苏慢，后发先至”的情况。最终画面上是江苏省，但状态栈记录已经回到了全国，数据和地图全对不上。

解决方案有两种。一种是加锁：

let isLoading = false; async function drillDown(level, adcode) { if (isLoading) return; isLoading = true; try { // 原有下钻逻辑 } finally { isLoading = false; } }

另一种是给每次操作加一个自增序号，响应返回后只有最新的序号才允许渲染。我更推荐加锁方案，因为交互上“进行中禁止再次点击”本来就是合理的，同时还可以在按钮上给一个loading状态，比静默忽略更友好。

4.3 返回后的视口重置

下钻时我设置了center和zoom来聚焦省份，返回上一级如果不重置，地图就会停在刚才缩放的位置。比如从南京返回江苏，地图还是南京地区的缩放级别，用户会一脸懵。所以返回时一定要把上一级地图的center和zoom重新计算一遍并写进setOption里。

我的做法是在构建option时始终传入center和zoom，这两个值由calcView(geoJson)计算得出，而不是手动写死。这样不管从哪一级返回，地图视角都会自动回到一个合适的全貌，用户也不会因为视角位置不对而误以为代码出了问题。

4.4 事件绑定顺手清理

虽然我前面说事件只需要绑定一次，但如果你确实用到了临时事件的场景，比如在某个层级临时监听一个特殊点击行为，记得用chart.off('click', handler)解绑。大屏项目通常7x24小时挂机，事件循环累积多了，页面会越来越迟钝。最好一开始就把事件管理当成和状态管理一样重要的事情对待，而不是等项目跑起来了再回头补。

5. 真实项目里的性能与体验优化

5.1 大量散点数据的渲染

市级地图如果叠加几千个门店的点位，直接渲染会有压力。ECharts的scatter有large模式：

{ type: 'scatter', large: true, largeThreshold: 2000, data: points }

large模式会走更高效的绘制路径，对大数据量有明显改善。如果数量到了几万级别，建议后端先做聚合，比如把门店聚合成网格点、热力点，而不是把所有原始点位都抛给前端。大屏上看得是趋势，不是每一个点的精确位置，聚合带来的视觉损失几乎可以忽略。

5.2 地图数据体积的持续压缩

前面提到过用mapshaper压缩GeoJSON，这里再说个具体的用法。命令行工具一行就能搞定：

npx mapshaper 320000_full.json -simplify dp 15% -o 320000_full_simple.json

这条命令的意思是用Douglas-Peucker算法保留约15%的点，输出一个瘦身版的文件。我在实际项目里把全国地图从4MB压到600KB，视觉上边界还是那个轮廓，加载速度和渲染速度都有质的提升。地图数据的精度选多少，取决于你的屏幕尺寸和展示层级，大屏一般不需要街道级的细节，压缩比例可以大胆一些。

5.3 resize与移动端的适配问题

大屏项目经常运行在特殊分辨率的屏幕上，甚至可能需要适配iPad、手机竖屏。地图容器尺寸变化时，要监听window.resize事件并调用chart.resize()。

如果做大屏按钮和文字的自适应，可以配合transform: scale()方案，把一整块大屏按照设计稿缩放，而不是每个像素适配。这种方式下chart.resize()不用频繁触发，地图内部坐标也不会因为缩放产生漂移。移动端还要注意一下点击事件和roam缩放手势的冲突，实测直接启用roam: true在手机上可以正常双指缩放，无需额外处理。

5.4 从2D联动扩展到3D地图

如果你想让视觉效果更震撼，ECharts官方生态里的echarts-gl提供了map3D组件，它同样可以配合scatter3D做立体散点。联动逻辑并没有变，变的只是配置层级：series里的type换成map3D，坐标系从geo换成globe或map3D的坐标体系。

series: [{ type: 'map3D', map: `area_${adcode}`, shading: 'lambert' }]

需要注意的是，map3D对机器性能要求更高，动画过度也多一些，一般只建议用在展厅大屏这种特定场合。Web页面里用2D联动加上好的配色和交互细节，已经能覆盖绝大多数业务诉求。

在我自己做过的几个大屏项目里，三级联动真正花时间的不是ECharts本身的配置，而是数据边界和状态管理。把数据接口设计成“区域编码+层级”的结构，把状态栈在动手写代码之前想透，后面所有下钻、返回、面包屑跳转都只是顺水推舟的事。最后分享一个小经验：开发阶段可以在URL上加参数直接指定初始层级和区域，比如?level=city&adcode=320100，这样调试市级视图时不用每次从全国点进去，能省下不少重复操作的时间。

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