简介：本资源提供一份适配 ECharts 的东莞区域地图坐标 JSON 数据，重点面向需要在地理可视化项目中展示广东东莞各行政区划的开发者，解决地图边界坐标难找、格式不匹配等问题。压缩包内共 1 个 JSON 文件，大小约 199KB，文件即地图数据本体，可直接用于 ECharts map 配置或结合业务数据做分级展示。该 JSON 中包含东莞各街道/区镇的边界经纬度坐标，结构清晰，适配 ECharts 地图组件加载，省去手动整理与转换坐标的繁琐流程。目前已有 1200 余人学习下载，实用性得到一定验证。借助此份数据，开发者可在图表库中快速渲染东莞地图，并叠加 visualMap、标签高亮、缩放漫游等交互能力，适合电商区域分析、人口分布、销售统计等场景；数据文件体积小、加载快，也便于二次编辑和扩展，是前端数据可视化工作中可直接使用的底层素材。

1. 东莞地图数据，为什么总在 ECharts 里翻车

做前端可视化的人，十有八九都栽在“拿不到一份干净的地图 JSON”上。ECharts 官方示例里跑得好好的中国地图、世界地图，一换成东莞这种地级市，就开始出幺蛾子：区域边界对不上、区县名称显示不全、放大拖拽后图形发虚、甚至整个地图直接渲染成空白。说白了，问题基本都出在地图坐标数据上——要么你用的 GeoJSON 精度不对，要么坐标系本身就偏了，要么数据里混进了多余的多边形。这篇文章要讲的，就是弄到一份能给 ECharts 用的最新东莞区域地图坐标 JSON 数据，把它清洗到能直接上生产环境，并且把那些最容易踩的坑提前排掉。东莞这座城市比较特殊，不设区县一级的行政单位，但在地图可视化里我们通常按街道、镇街来拆分区域，这里的“区域”指的就是这一层。适合谁看？前端工程师、数据分析师，以及所有被地图数据折腾过的人。

2. 先搞清楚 ECharts 地图 JSON 到底是什么：结构、坐标系和区域层级

2.1 GeoJSON 的结构：FeatureCollection 与 MultiPolygon

ECharts 地图数据走的是标准的 GeoJSON 格式。你拿到的所谓“东莞地图 json”，本质上是一个 FeatureCollection 对象，里面装着若干 Feature，每个 Feature 代表一个具体的区域（比如某个街道或镇街）。每个 Feature 里头最重要的字段是 geometry，它描述了这个区域的边界形状；其次是 properties，存放区域的名称、编码之类的属性信息。

geometry 的坐标类型里最常用的两种是 Polygon 和 MultiPolygon。Polygon 是一个由坐标点组成的闭合环，通常第一个环是外边界，后面的环是内部的空洞——比如一个镇区里如果真的有一块飞地不属于它，或者有湖面被单独抠掉，就会用多个环来表达。MultiPolygon 则是由多个 Polygon 组成，适用于一个区域在地理上被切割成多块的情况。东莞有几个街道在地图上有飞地，所以你在处理数据时会看到 MultiPolygon 出现，这很正常。

2.2 坐标系：一个最容易忽略的地图偏移陷阱

地图数据的坐标系有两种常见标准。一种是 WGS-84，也就是 GPS 直接输出的原始坐标；另一种是 GCJ-02，国内地图厂商普遍使用的加密坐标系。两者的差异大概在几百米量级，在高德、百度这类地图上采集的数据往往都是 GCJ-02 的。如果你直接把这种数据丢给 ECharts，ECharts 本身不做任何坐标转换——它的后端地图服务是可以指定坐标系的，但本地加载的 GeoJSON 完全看数据本身——结果就是你画出来的东莞地图跟底图错位，区域边界和卫星图对不上。

判断数据用的什么坐标系，最直接的办法是看边界坐标范围。东莞大致位于东经 113.4 度到 114.3 度、北纬 22.7 度到 23.1 度之间。如果你拿到的 JSON 里坐标数字在这个量级，优先怀疑是 GCJ-02 加过密的；如果坐标落在 113 度附近但边界明显偏了，十有八九就是坐标系不统一。市面上能下载到的东莞地图数据来源也很杂，有的从某地图平台直接抓的、有的从开源社区转存的，坐标系到底什么来路没人保证。我的习惯是先做一个坐标范围检查，再决定要不要做转换。

2.3 区域的层级：东莞的地图应该拆到哪一级

东莞和其他地级市最大的不同是：它不设市辖区，市直接管辖街道和镇。所以在做 ECharts 地图时，“区域”的下钻层级一般直接落到镇街一级，也就是 33 个左右（含园区）。如果你的数据源给的是“东莞—区—街道”三级结构，那大概率是把其他城市的模板套过来了，需要先做清洗合并，把中间的空层级去掉，再把名称统一成 ECharts 里能识别的镇街名。

这里有一个很实际的坑：不同来源的数据，镇街名称可能不完全一致。比如有的写“东城街道”，有的写“东城区”，有的直接写“东城”。ECharts 的 map 组件匹配数据是靠 name 字段做映射的，名称对不上，那个区域就渲染成空白或者不显示统计值。所以在把 JSON 丢进项目之前，先要有一份标准的镇街名称表，对照着去清洗你的数据。

3. 获取并清洗东莞地图 JSON：从下载到可用的一整套流程

3.1 三个可靠的获取路径与选型理由

获取东莞地图 GeoJSON，常见的路径有三条。第一条是直接从开源地理数据社区下载已经处理好的全国或广东地图数据，从中提取东莞部分。这类数据的优点是规范、统一命名；缺点是不一定是最新行政边界，而且往往带有大量你不需要的属性字段。第二条是从在线的坐标拾取工具或地图数据转换平台导出指定区域的 JSON。优点是区域裁剪精准、坐标系可控；缺点是部分平台导出的数据体积偏大，多边形顶点没有简化，直接喂给浏览器会导致渲染卡顿。第三条是自己在可视化工具里手绘或用已有底图数据重新矢量化。这个一般不建议，除非你对东莞各镇街边界极其熟悉，否则手工画出来的边界精度差、工作量也大。

就落地而言，我一般建议走第一条路打底，然后用第二条路做校验和补充。先拿一份已知可用的东莞基层数据，再对照在线平台导出的数据看边界形状是否吻合、名称列表是否齐全。两条路的数据交叉验证过，心里才有底。

3.2 用脚本裁剪出东莞范围的 GeoJSON

多数情况下，你拿到的全国或广东地图数据是一个完整的 FeatureCollection，里面包含所有地级市的 Feature。东莞作为其中一个 Feature，直接裁剪出来即可。下面这个脚本做的事情是：读入全国数据，筛选出 name 为“东莞市”的 Feature，再把它单独写到新文件里。

import json # 读取全国/广东省的 GeoJSON 数据 with open('guangdong.json', 'r', encoding='utf-8') as f: data = json.load(f) # 筛选出东莞对应的 Feature，注意名称可能因数据源而异 features = [ feature for feature in data['features'] if feature['properties'].get('name') == '东莞市' or feature['properties'].get('adcode') == '441900' # 东莞市的行政区划代码 ] if not features: print('未找到东莞市数据，请检查字段名或行政区划代码') else: # 构造新的 FeatureCollection dongguan = { 'type': 'FeatureCollection', 'features': features } with open('dongguan.json', 'w', encoding='utf-8') as f: json.dump(dongguan, f, ensure_ascii=False, indent=2) print(f'已提取 {len(features)} 个东莞区域 Feature')

这个脚本里有个关键判断：按name或adcode两个字段去匹配，因为不同数据源的属性字段命名差异很大。有的用name，有的用adcode，有的用properties.fullname。如果你对数据源字段不熟悉，建议先把读入数据的properties字段打印出来看一眼，再改匹配规则。行政区划代码 441900 是东莞的，这个比名称可靠得多，因为同一个城市在不同数据源里的名称可能带后缀或编码方式不同，但 adcode 基本是稳定的。

不过这还只是拿到了“东莞市”的整体边界。如果你需要的是分镇街渲染，这个整体边界是不够的，你需要的是东莞下辖各镇街各自的 Feature。这时候常见的做法是获取广东省的镇街级数据，再按adcode前缀过滤——东莞所有镇街的代码都从 441900 开头。从省一级拿到镇街级数据后，过滤逻辑只需要把adcode的匹配条件改成前缀匹配即可，代码如下：

features = [ feature for feature in data['features'] if str(feature['properties'].get('adcode', '')).startswith('441900') ]

注意，如果你拿到的数据里东莞只是单个 Feature 而没有镇街子数据，那就需要另外获取镇街级的边界数据源。东莞本身的行政区划特殊，市面上打包好的“东莞镇街 GeoJSON”不算多，很多是需要从更大范围的数据里切出来的。这也是为什么很多人选择直接搜索“东莞镇街 geojson”找现成数据包——如果找来的数据包能直接用还好，不能直接用就得靠脚本清洗。

3.3 清洗数据：简化边界、统一命名、压缩体积

拿到原始的镇街级数据之后，下一步是清洗。这一步直接决定浏览器渲染性能。原始数据往往包含极高密度的坐标点，单个镇街的多边形可能有几万甚至十几万个点，全部塞给 ECharts 会让地图缩放、拖拽时的帧率掉到没法看。

// mapshaper 命令行工具，用于简化 GeoJSON 多边形边界 // 安装：npm install -g mapshaper // 1. 查看数据基本信息 mapshaper dongguan-town.json -info // 2. 简化边界，保留 0.2% 的顶点，输出为新的 GeoJSON mapshaper dongguan-town.json -simplify dp 0.2% -o format=geojson dongguan-simple.json // 3. 如果担心简化后边界越过原边界，用内外缓冲区折中 mapshaper dongguan-town.json -simplify dp 0.2% keep-shapes -o format=geojson dongguan-simple.json

这里dp指定的是 Douglas-Peucker 算法，0.2%表示保留原始顶点的千分之二。这个值不是固定的：如果只做省市级别的展示，千分之一甚至万分之一都够；如果要做镇街级别的高精度交互，建议从1%开始往下调，边调边在浏览器里检查边界是否明显变形。keep-shapes参数用来防止面积太小的多边形在简化过程中被整体吞掉——东莞有些小的街道地块面积不大，不加这个参数有可能直接被简化成一个点或者消失。

坐标简化是必要的一步，但不要过度简化。我之前就试过把一个东莞地图的数据压到万分之一，结果是地图渲染确实流畅了，但部分镇街的边界看起来跟手绘的差不多，形状严重失真，放到大屏幕上非常明显。建议至少保留0.5%的顶点比例，然后看实际效果再降。

统一名称这一步同样可以用脚本批量处理。拿到数据后，先打印出所有properties.name字段，跟一份标准镇街名单对比，凡是不一致的都要改。常见的差异是后缀缺失、简繁体不一、或者混入了历史名称。清洗逻辑用一个简单的字典映射即可：

import json # 打开清洗后的数据 with open('dongguan-simple.json', 'r', encoding='utf-8') as f: data = json.load(f) # 名称映射，把非标准名称统一成标准名称 name_map = { '东城': '东城街道', '东城区': '东城街道', '南城': '南城街道', '南城区': '南城街道', # 实际项目中按需扩展 } for feature in data['features']: old_name = feature['properties'].get('name', '') if old_name in name_map: feature['properties']['name'] = name_map[old_name] with open('dongguan-cleaned.json', 'w', encoding='utf-8') as f: json.dump(data, f, ensure_ascii=False, indent=2)

注意一个细节：改造后的数据里properties字段除了name外，可能还留着adcode、childrenNum这种无用字段。为了减小体积，可以只保留name和adcode。这部分可以顺手在上一段脚本的循环里加一行feature['properties'] = {'name': ..., 'adcode': ...}，把整个 properties 替换掉。

3.4 进度检查：拿到一份可用数据后先验证再投入

清洗完之后先不要急着接入 ECharts。最简单的验证方法是把数据拖到任意一个支持 GeoJSON 预览的在线工具里，肉眼检查几个点：东莞的整体轮廓是否完整、镇街边界是否光滑、有没有哪个街道的形状明显不对（比如被切了一刀、多出来一块）。这一步能筛掉大部分数据源本身的问题。第二步是用脚本做一次边界自检——检查每个 Feature 的坐标环是否闭合、相邻镇街边界是否有大的缝隙。这一步不是必须，但如果你要做的项目对精度要求高（比如在地图上做区域圈选），就值得做。

# 快速检查坐标环是否闭合 import json with open('dongguan-cleaned.json', 'r', encoding='utf-8') as f: data = json.load(f) for feature in data['features']: geom = feature['geometry'] coords = geom['coordinates'] # 检查每个 polygon 的首尾坐标是否相等 if geom['type'] == 'Polygon': rings = [coords] else: rings = coords for ring in rings: for polygon in ring: if polygon[0] != polygon[-1]: print(f"边界未闭合: {feature['properties'].get('name')}")

这个检查脚本的逻辑很简单：一个封闭的多边形，它的第一个点和最后一个点必须完全相同。如果数据源本身有问题，这里会直接暴露出来。未闭合的边界在 ECharts 里通常不会报错，但渲染出来的区域可能出现一条可视的“裂缝”，很影响观感。一旦发现问题，直接换数据源比手动修补更省事。

4. 把 JSON 接入 ECharts：注册地图、配置 series 和三个必调参数

4.1 最小接入命令：registerMap 与 geo 组件

清洗好的 JSON 数据，要真正用到 ECharts 里，核心就两个步骤：注册地图，然后在地图组件或 series 类型中引用它。注册使用的是echarts.registerMap方法，它接收两个参数：一个是你给这个地图起的名字，另一个就是解析后的 GeoJSON 对象。名字可以随便起，但建议有语义，后面要在 option 里反复引用。

import * as echarts from 'echarts'; import dongguanGeo from './assets/dongguan-cleaned.json'; // 注册地图，名字与后续 option 中的 map 字段保持一致 echarts.registerMap('dongguan', dongguanGeo); // 初始化实例 const chart = echarts.init(document.getElementById('map-container')); // 基础配置：使用 geo 组件展示地图，不绑定数据 const option = { geo: { map: 'dongguan', roam: true, // 允许缩放和平移 itemStyle: { areaColor: '#e0e0e0', borderColor: '#333' } } }; chart.setOption(option);

这段代码是接入地图的最短链路。geo组件是纯地图展示用的，适合做底图；如果你想在每个区域上叠加数据分布，比如展示各镇街的常住人口，那就要用series里的map类型。区别在于geo只管画地图，而series-map需要额外接收数据数组，并根据name匹配把数值映射到对应区域的颜色上。二者也可以同时存在，通过geoIndex关联。

4.2 配置数据映射：series-map 和 visualMap 的配合

用 series-map 显示镇街维度的数据，是东莞地图可视化里最常见的落地形态。你需要准备两份东西：一份是地图 JSON（已清洗好的），另一份是所有镇街的统计值数组。数组项的结构是{ name: '东城街道', value: 20000 }，name必须和 JSON 里properties.name完全一致，value是你自己的业务数据。

const option = { tooltip: { trigger: 'item', formatter: function(params) { return params.name + '：' + params.value; } }, series: [{ type: 'map', map: 'dongguan', roam: true, emphasis: { label: { show: true, fontSize: 14, fontWeight: 'bold' } }, data: [ { name: '东城街道', value: 12000 }, { name: '南城街道', value: 8600 } // 其他镇街数据按需补充 ] }], visualMap: { min: 0, max: 20000, text: ['高', '低'], realtime: false, calculable: true, inRange: { color: ['#e0f3f8', '#abd9e9', '#74add1'] } } };

tooltip 这里如果用默认的，鼠标悬浮时会把整个对象打印出来，不够直观。formatter回调里拿到params.name和params.value，自己拼格式是最可控的。visualMap是区域填色的关键，min和max决定颜色映射的范围，这个值要看你业务数据的分布来定——如果数据最小值是 8000、最大值是 15000，但你硬把范围设在 0 到 50000，那所有区域看起来都是同一个低色值，颜色区分度会很差。inRange.color里的数组是有序的，低值对应第一个颜色，高值对应最后一个颜色，中间自动插值。

4.3 三个必调参数：roam、label、aspectScale

接入之后，有三个参数几乎每次都要调，而且调不好直接影响使用体验。

第一个是roam。这个参数控制地图是否允许鼠标拖拽、滚轮缩放，默认是false，很多人接入后地图动不了，就是忘记了它。但也不是无脑设成true就完事。如果你的地图是嵌在一个会滚动的页面里的，开启roam会跟页面的滚动事件抢操作——鼠标悬停在地图上滚轮时，页面不滚了，但地图在缩放，这个交互冲突很恼人。处理方式是判断场景：地图占据大块独立区域时开roam: true；地图只是页面里一个局部模块，用户主要在滚动页面时，就不要开，或者只在缩放按钮上做交互。

第二个是label的显隐控制。东莞的镇街密集，小的镇街在地图上占的面积很小，如果所有标签默认全开，文字会互相重叠，整个地图看起来是一团糊的。我一般会在series[i].label.show设为false，只在emphasis状态下开启——也就是鼠标移到某个区域上才显示它的名字。这样既保证图面干净，又不耽误用户识别。

第三个是aspectScale。这个参数用于控制地图的宽高比缩放——某些数据源因为坐标精度问题，渲染出来的地图会被压扁或者拉长。正常比例的地图不需要动它，但如果你发现地图变形明显，优先检查数据坐标系而不是调整这个参数。它属于“最后的手段”，因为它只是视觉上拉伸，并不会修正实际坐标偏移。

4.4 在项目里按需加载地图 JSON：体积与加载策略

地图 JSON 文件的体积通常在几百 KB 到一两兆之间。如果你是在传统项目里用<script>标签直接引 ECharts，这个 JSON 直接前置引入也不算太慢；但如果你的项目是 Vue/React 这种单页应用，JSON 应该走异步加载，而不是在入口文件里同步 import。比较轻量的一种做法是用fetch动态拉取，拿到 JSON 后再用registerMap注册：

fetch('./geojson/dongguan-cleaned.json') .then(res => res.json()) .then(geoJson => { echarts.registerMap('dongguan', geoJson); // 初始化图表并 setOption initChart(); }) .catch(() => { console.error('东莞地图数据加载失败'); });

这样做的直接收益是：首屏不阻塞，地图数据什么时候要用什么时候拉。如果你的项目里还要做东莞下钻到街道的功能，那代码结构就要调整成先注册市级边界，点击后再异步加载镇街级边界。这个做法留到最后一章展开。

5. 东莞地图数据使用中的常见问题与排查方法

5.1 地图渲染出来是空白，F12 没有任何报错

这是最玄学也是最容易让人心态爆炸的问题之一。现象是你已经把 JSON 注册进去了，option 也配置了，页面打开后地图区域是空白，控制台干净得像没跑过代码一样。先别怀疑 ECharts 本身，按下面的顺序排查。

第一步检查注册名与引用名是否一致。registerMap('dongguan', geo)里的名字和你option.series[0].map中的名字一字不差才算匹配。第二步检查 JSON 是不是真的被加载了。有些项目里用的是静态资源服务器，路径配错的情况下fetch静默失败，代码没走到注册那一步。第三步也是最容易被忽略的——检查map属性是否设成了当时内置地图的名字，比如'china'，而你的注册名是'dongguan'，不匹配就渲染空白。

提示：遇到地图空白问题时，打开浏览器 Network 面板看这个 JSON 文件的请求状态码。如果 404，先解决资源路径；如果 200 但内容为空，那就是数据本身被截断了。

5.2 地图能渲染，但个别镇街没有响应

地图整体显示出来了，但鼠标点到某一个镇街时，tooltip 不弹、hover 不高亮，好像这块区域是“死”的。最常见的现象是某个镇街——比如面积较小的某街道——看起来在地图上存在，但点不中。原因几乎都是数据匹配问题。你注册的地图 JSON 里这个区域的name和你data数组里的name不一致。ECharts 的匹配逻辑是严格字符串相等，多一个空格、少一个“街道”后缀都匹配不上。

解决办法是打印出地图 JSON 里所有properties.name列表和你的业务数据里的名称列表，做一次全量 diff。如果数据量不大，手工修正即可；如果你的业务数据来自后端接口，那就要后端在返回数据前先做名称标准化，确保和地图 JSON 对齐。反过来也一样——地图 JSON 里的名称应该和业务侧统一，而不是业务侧迁就地图。因为地图数据通常是静态的，改起来便宜，业务数据的名称可能是从数据库字段里带出来的，动那里牵连更广。

5.3 地图偏移了：整体位置和底图对不上

如果你在地图底层叠了高德或 Google 的瓦片底图做叠加展示，会明显看到 ECharts 里的东莞轮廓跟底图上的东莞轮廓位置对不上，相隔几百米到一两公里。这就是典型的坐标系不一致。ECharts 自身不做坐标转换，它只是把 GeoJSON 里的坐标点原样画出来；如果 JSON 数据是高德系坐标，而你的底图是其他坐标系的，两套坐标就错位了。

常见做法是换数据源——找一个和你底图坐标系一致的 GeoJSON。如果你的底图是天地图或 ArcGIS 切片，通常用 WGS-84 或 CGCS2000 的数据；如果你的底图是高德，那数据尽量也用 GCJ-02 的。如果你只能拿到一种坐标系的数据，要对数据做统一偏移，市面上有针对常见坐标系的转换工具库，本质是个数学变换。但这里提醒一句：这个转换对单个点做容易，对整个多边形做也容易，精度能接受就行——它本来就是加密算法的近似逆运算，存在系统误差，不要指望完美对齐。

5.4 地图渲染正常但缩放一卡一卡的

地图能显示，但每次缩放都要等半秒甚至更久，这基本是数据结构没优化到位。上文提到的顶点简化没做，是最常见的原因。你能下载到的一些源码性质的 GeoJSON 数据，坐标点极其密集，单个 Feature 有上万个顶点，这在桌面浏览器里已经能感到卡顿，放到移动端直接卡死。

解决方向有两个：第一，做边界简化。用 mapshaper 或者其他简化工具把顶点数量降到合理区间，这是治本。第二，如果你不想动数据，只想优化渲染，可以在 ECharts 配置里调低一些渲染相关的参数，但这只是治标。地图类图形本质上是大量路径的绘制，顶点越多、绘制压力越大，没有捷径。还有一个容易被忽略的小点：地图数据是 JavaScript 对象，在渲染时会参与垃圾回收和属性查找；如果你用了一个体积特别大的对象——比如属性字段特别多——也会拖慢性能。清洗时顺手精简properties，收益比想象中大。

5.5 区域名称被截断或被挤到地图外

label 文字显示不全，或者落在图形外面。这种情况集中出现在面积比较小的镇街上。原因很简单：区域本身在地图上占的像素太少，放不下文字。解决办法不是去调字体大小——那是把问题从这个小区域扩散到其他区域——而是让 label 默认不显示，或者使用overflow、width等标签样式属性做截断控制。如果确实需要每个区域都显示名称，且区域内放不下，可以考虑在地图上用 markPoint 类型添加独立的文字标注，位置手动调整。这块的本质是地图设计的范畴，不是技术上能不能做，而是做了之后图面是否还能看。东莞镇街密度高，开全标签基本都是一团糟，尽量克制。

5.6 JSON 文件加载成功却被浏览器拦截

在本地开发环境里一切正常，部署到服务器上后地图不显示，控制台报错是跨域或者 MIME 类型问题。这类问题的根源在于你用的是fetch加载 JSON 的方式。有些静态服务器对.json文件返回的 MIME 类型是application/octet-stream而不是application/json，误触发一些浏览器的安全策略。解决办法有两个：一是调整服务器配置，对.json文件返回正确的 MIME 类型；二是绕过 fetch，把 JSON 转成.js文件，用export default或全局变量暴露出来，然后直接 script 引入。第二种办法在跨域问题得不到解决的环境里更省心——项目部署在别人家的服务器上，没法改配置的情况，用 JS 文件最稳。

6. 从静态地图到可交互下钻：让东莞地图数据真正用起来

地图 JSON 的价值，在于能不能支撑完整的交互链路。很多人的需求不是画一张静态图，而是做成“广东省 → 东莞市 → 镇街 → 具体点位”这种可下钻可回退的交互。这里的关键在于数据的组织方式：你需要的不只是一份东莞的 GeoJSON，而是一组按层级组织的 GeoJSON 文件。这里以东莞作为有镇街数据的地级市为例，一套最省心的下钻逻辑是提前把数据分成“东莞市级边界”和“东莞镇街级边界”，在下钻时动态换数据。

一个推荐的做法是：把所有镇街数据合并进一个单独的 JSON 文件里，然后在下钻到东莞时，用registerMap重新注册一次镇街级地图。这样用户点击东莞市时拿到镇街视图，点击其他城市时再切回来。核心逻辑就是一个加载函数，通过fetch动态拉取对应层级的 JSON。

async function loadMap(level, boundaryName) { const res = await fetch(`./geojson/${level}-${boundaryName}.json`); const geo = await res.json(); echarts.registerMap(boundaryName, geo); return boundaryName; } // 首次加载：展示广东省地图 const mapName = await loadMap('province', 'guangdong'); chart.setOption({ series: [{ type: 'map', map: mapName }] }); // 用户点击广东省地图中的东莞市后，加载镇街级地图再重新 setOption chart.on('click', function(params) { if (params.name === '东莞市' && currentLevel === 'province') { const townMapName = await loadMap('town', 'dongguan'); currentLevel = 'town'; chart.setOption({ series: [{ type: 'map', map: townMapName, data: townData }] }); } });

下钻逻辑里最容易被忽略的是事件绑定的顺序和图层替换的时机。每次setOption之后，旧的点击事件监听还挂在 chart 实例上，如果不做节流或者标志位判断，用户快速连点两次会触发两次重复的加载和注册，轻则重复请求，重则地图数据错乱。上面代码里的currentLevel就是一个保护标志，每一次点击先判断当前层级，避免重复下钻。

另外一个提升体验的技巧是记忆地图状态。用户在下钻到镇街视图后，放大缩放了某个位置，结果点击“返回省级”再下钻回来，地图又回到了初始视角。这个问题的根源在于每次setOption时地图的缩放中心和缩放等级都被重置了。解决方式是在每次切换层级前，通过chart.getOption()拿到当前的geo或series里的zoom和center，记录下来；切换回来后重新设置这两个字段。这些参数在 ECharts 里是可写的，直接通过setOption传进去就能恢复视角。

说到底，一份好的东莞地图 JSON 是整个地图可视化项目的地基。清洗时多花半小时做边界简化、名称统一和坐标系确认，后续使用中能省下大量排查时间。我自己就把踩过的坑记成了一份清单：任何地图数据进项目前必须过三个检查——名称能对上业务数据、坐标范围在合理区间、边界已简化。这三关过了，剩下的都是配置层面的小问题。地图可视化的数据链路并不复杂，坑都在细节里。希望这篇笔记能帮你把东莞地图数据这块硬骨头啃下来，少走几步弯路。

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