简介：地理空间数据可视化中，地图偏移问题往往与底层数据模型和坐标配置密切相关。GeoJSON作为存储地理要素的开放标准，其经纬度范围直接决定了地图的渲染位置。ECharts作为主流可视化库，内置的geo坐标系通过解析GeoJSON中点的坐标来映射地图，但默认以0度经线为中心，导致中国等东亚区域显示偏左。要解决这一问题，需要从数据源坐标范围与geo组件参数两个层面协同调整。掌握center、layoutCenter、boundaryGap等属性的原理，不仅能精准实现“中国居中”，也为大屏项目中的地图交互、数据钻取和视觉优化提供坚实基础。该技能广泛应用于数据大屏、报表分析及地理信息系统等场景，帮助开发者快速构建符合业务视角的可视化地图，提升信息传达效率。

1. 做一张以中国为中心的 echart 世界地图：问题不在 world.js，而在你的 geo 配置

做过大屏的应该都有这个经历：想搞一张以中国为中心的 echart 世界地图，搜半天下了一个world.js，注册地图、setOption 一气呵成，结果中国被挤在地图最左边，右边空出一大截大洋。你以为文件坏了，换一个源重新下载，还是一样。这个现象不是 world.js 的锅，而是 ECharts 的 geo 坐标体系默认按 0 度经线左右均分，中国在东经 73° 到 135°，自然被甩到左侧。要让它居中，你得同时处理两件事：一是 GeoJSON 数据里的坐标范围，二是 geo 组件里 center 和 boundaryGap 的组合。这篇文章就按「数据长什么样 → 怎么加载 → 参数怎么调 → 交互怎么做 → 坑在哪」这个顺序，把整条链路讲透，最后附上我在大屏项目里一直在用的验证方法。适合刚接手可视化大屏、被地图居中折腾过一晚的开发者，也适合想深入了解 ECharts 地图机制的人。

2. world.js 里的秘密：GeoJSON 坐标与地图居中的关系

2.1 world.js 到底是什么，为什么它决定地图位置

业界常说的 world.js，本质上是一个 GeoJSON 格式的世界地图数据文件，通常以world.js或world.json的形式出现，里面是一串描述每个国家边界经纬度坐标的数组。ECharts 加载它之后，通过内置的 geo 坐标系把经纬度映射到 canvas 或 SVG 上，最终画出你看到的地图。所以地图的位置由两个因素决定：文件中每个点的经纬度数值，以及 ECharts 渲染时对坐标范围的处理方式。

公开渠道下载的 world.js 大多基于自然地球数据，坐标范围通常是经度 0° 到 360°，纬度 -85° 到 85°。ECharts 拿到这份数据后，如果没有显式设置，它会按照数据的最小外接矩形去计算视野范围，于是地图的左右边界分别在 0° 和 360°，中心点就在 180° 附近。中国在东经 73° 到 135°，落在整个范围的左侧三分之一处，看起来就是「偏左」。而网上很多教程教的「改 center: [135, 35]」其实只对了一半，因为 ECharts 的 center 参数是相对当前坐标范围的比例位置，而不是绝对经纬度，直接填 135 并不能保证中国居中。

正确的做法是两种：要么在数据层面把每个点的经度减去 360，让坐标范围变成 -180° 到 180°，然后 center 设 [0, 35] 或 [10, 35] 附近，要么在 geo 配置里用 boundaryGap 和 layoutCenter 的组合，把地图容器整体向右平移。第一种改数据的方案对地图本身的几何形状有影响，会使地图被剪切过；第二种方案需要用 layoutCenter 和 layoutSize 控制地图在 canvas 中的位置，实际上是裁剪容器里的显示区域，把中国移到中间。下面分别展开。

2.2 先看清楚world.js内部长什么样：三种方式检查坐标范围

拿到一个 world.js，不要急着写代码，先确认它的坐标范围。常见做法是直接在浏览器控制台里执行一段脚本，把文件加载后打印出来。下面这段代码假设你用的是world.js，它通常通过 script 标签引入，挂在一个全局变量上。

// 假设页面里已经用 <script src="./world.js"></script> 引入 const raw = window.worldJson || window.world || window.echartsMapWorld; // 有的 world.js 暴露的是 { features: [...] }，有的是数组，先做兼容 const geoJson = raw.features ? raw : { features: raw }; let minLng = Infinity, maxLng = -Infinity; let minLat = Infinity, maxLat = -Infinity; geoJson.features.forEach(feature => { const geom = feature.geometry; if (geom.type === 'Polygon') { geom.coordinates.forEach(ring => { ring.forEach(([lng, lat]) => { if (lng < minLng) minLng = lng; if (lng > maxLng) maxLng = lng; if (lat < minLat) minLat = lat; if (lat > maxLat) maxLat = lat; }); }); } else if (geom.type === 'MultiPolygon') { geom.coordinates.forEach(polygon => { polygon.forEach(ring => { ring.forEach(([lng, lat]) => { if (lng < minLng) minLng = lng; if (lng > maxLng) maxLng = lng; if (lat < minLat) minLat = lat; if (lat > maxLat) maxLat = lat; }); }); }); } }); console.log('经度范围:', minLng, '~', maxLng); console.log('纬度范围:', minLat, '~', maxLat); console.log('国家数量:', geoJson.features.length);

这段脚本的逻辑是递归遍历 GeoJSON 里每个要素的 Polygon 或 MultiPolygon 坐标，取出所有经纬度的最小值和最大值。跑完之后你能直观看到手里的文件到底是多少到多少的坐标范围，是 0 到 360 还是 -180 到 180，这直接决定了后续 center 怎么写。如果打印出来是 0 到 360，说明你需要用第二种方案或者做数据偏移；如果是 -180 到 180，那中国还是偏左，因为中心经度 0 在左边，但至少坐标系是标准的，改 center 就能解决。

除了脚本检查，还可以用文本编辑器直接打开 world.js 看前几行。文件头部通常是{ "type": "FeatureCollection", "features": [...] }，浏览其中任意一个国家的坐标数组，多看几个就能总结出经纬度的大小范围。注意有些文件是[lat, lng]的顺序，有些是[lng, lat]，ECharts 要求后者，如果你发现纬度值跑到 100 以上，多半是反了，后面地图会变成一团乱麻。

2.3 为什么0~360才是导致中国在左侧的根因

按 0 到 360 的坐标范围来算，ECharts 会把地图渲染在一个宽度为 360 的虚拟坐标空间里，中心经度大约在 180。如果你直接设置center: [180, 0]，地图整体不会动，因为那本来就是默认视野的中点；设置center: [135, 35]会让视野中心向亚洲偏移，但因为数据范围还是 0 到 360，地图容器右边界大约在 360，左边界在 -90，中国虽然靠近中心了，可整个地图的边界也被推出去了，右侧会空出一块。

如果数据是 -180 到 180，那默认中心经度是 0，欧洲和非洲在正中，中国依然在右侧边缘。这时你把 center 改成 [30, 30] 左右，整个视野的中心就往东移了 30 度，中国就滑到中间。很多网上代码直接复制center: [135, 35]，就是没搞清楚自己的数据源到底是哪套坐标范围。

所以第一步永远是搞清楚手里的 world.js 是 0 到 360 还是 -180 到 180，然后决定用哪种策略。下表是我在项目里判断用哪种方案的参考标准。

2.4 把 0~360 改成 -180~180：转换脚本与四个边界坑

如果你手里的 world.js 是 0 到 360 且你想通过改数据的方式让中国自然居中，最常见做法是写一段 Node 脚本，把每个坐标点的经度减去 180，让范围变成 -180 到 180，同时把跨越 180 度经线的国家（俄罗斯、美国、新西兰等）做拆边处理。

// transform.js const fs = require('fs'); const world = JSON.parse(fs.readFileSync('./world.json', 'utf-8')); function normalizeLng(lng) { // 把 0~360 转到 -180~180 let result = lng > 180 ? lng - 360 : lng; // 特殊情况：某些数据源在 180 附近有 180.0001 之类的值 if (result > 180) result = 180; if (result < -180) result = -180; return result; } world.features.forEach(feature => { const geom = feature.geometry; if (geom.type === 'Polygon') { geom.coordinates.forEach(ring => { ring.forEach(coord => { coord[0] = normalizeLng(coord[0]); }); }); } else if (geom.type === 'MultiPolygon') { geom.coordinates.forEach(polygon => { polygon.forEach(ring => { ring.forEach(coord => { coord[0] = normalizeLng(coord[0]); }); }); }); } }); fs.writeFileSync('./world-centered.json', JSON.stringify(world)); console.log('转换完成，经度范围已归一到 -180 ~ 180');

这段脚本做了两件关键事：一是把经度大于 180 的减 360，二是做了边界 clamp 防止浮点误差。参数 normalizeLng 里的判断逻辑是可逆的，对 0 到 360 的数据适用。跑完之后你得重新检查一遍边界坑：俄罗斯东部的楚科奇半岛横跨 180 度经线，原始数据的坐标可能是从 170 一路编到 190，转换后变成 170 到 -170，这样多边形首尾相连时会出现一条横跨整个地图的线，也就是常见的「地图撕裂」。这种问题需要额外拆线，把跨越 ±180 的多边形切成两个子多边形，我这里不展开，但你要知道有这个坑。

第二个坑是太平洋上的岛国，比如基里巴斯，经度范围横跨 170 到 -170，转换逻辑本身没错，但可视化时整个国家会被画在地图两侧，视觉上特别怪。第三个坑是某些文件里经度值本身就是 180.0000001 这种脏数据，clamp 到 180 后可能让边界稍微偏移，但肉眼一般看不出来。第四个坑是转换后的文件体积不变，但 ECharts 重新计算视野范围时，默认中心从 180 变成了 0，如果你不显式写 center，欧洲又回到了正中间，等于白忙一场。

所以我的建议是：与其改数据，不如先试配置方案。ECharts 的 geo 组件有layoutCenter和layoutSize两个参数，可以直接把地图容器往右平移，让中国落在中间，而不碰原始的坐标数据。这样最简单、也最容易维护，下面一章就来说这套最小配置怎么搭。

3. 载入 world.js 并让中国居中：一份最小可运行的 geo 配置

3.1 在 ECharts 里注册 world.js 地图：registerMap 的正确姿势

ECharts 从 5.x 开始，地图数据不再内置，你需要自己下载 GeoJSON 文件然后通过 registerMap 注册。这一步虽然简单，但经常有人因为引入方式不对而踩坑：比如有人用import world from './world.js'，结果拿到的是字符串而不是对象，代码直接报错。

常见做法是使用 script 标签引入 world.js，然后从全局变量里取数据。下面这段代码演示了在原生 HTML 里如何注册并创建一张基础世界地图，后续所有配置都基于这个模板。

// 引入 ECharts 和 world.js（已从 0~360 转换为 -180~180） // <script src="https://cdn.jsdelivr.net/npm/echarts@5/dist/echarts.min.js"></script> // <script src="./world-centered.js"></script> // world-centered.js 内部暴露了一个变量，通常是 window.worldJson const geoJson = window.worldJson; echarts.registerMap('world', geoJson); const chart = echarts.init(document.getElementById('mapContainer')); chart.setOption({ geo: { map: 'world', roam: true, // 允许缩放和拖拽 center: [20, 30], // 中心经度 20，纬度 30，让中国靠近视野中心 zoom: 1.5, // 适当放大，缩小两侧留白 boundaryGap: [0, 0], // 边界不留白，让地图顶满容器 itemStyle: { areaColor: '#e8e8e8', borderColor: '#888' } } });

这里的逻辑分三层：registerMap 把 GeoJSON 注册成名为 world 的地图；geo.map 引用这个名字；center 和 zoom 控制视野。center 我用的是 [20, 30]，这个值是基于 -180 到 180 坐标范围的经验值，它让中国经度 105 正好落在容器中间偏右的位置，因为 105 减 20 等于 85，而容器左边的跨度是 200（从 -180 到 20），右边是 160（从 20 到 180），中国左侧的亚洲大陆宽度小于右侧的太平洋宽度，视觉上地图是居中的。

3.2 center、zoom、layoutCenter 到底怎么配合：三个参数的分工与边界

center、zoom、layoutCenter 这三个参数最容易被混用，它们的职责完全不同。center 是视野中心点的经纬度，它会移动地图在容器中的位置但不会改变容器的可视区域大小；zoom 是缩放倍数，值越大地图细节越大但可见范围越小；layoutCenter 是地图在容器中的相对位置，可以把它理解为「把地图这张图钉在容器的某个百分比位置」，它的取值范围是字符串或数字，比如['60%', '50%']。

对于 0 到 360 的原始数据，虽然 center 也能往右调，但效果不如 layoutCenter 直接，因为此时整个坐标空间的跨度是 360，center 调 30 度只相当于把视野往右挪了不到 10%，容器右侧会露出一大块空白。而改用 layoutCenter 时，ECharts 会按你指定的百分比把地图的几何中心钉在容器里，不改变视野大小，地图不露白。

我一般在项目里用的策略是：数据范围是 -180 到 180 时，用 center 微调，zoom 控制细节；数据范围是 0 到 360 时，先跑一遍转换脚本，或者直接用 layoutCenter 把地图往右平移。下面是一段完整的配置片段，满足「中国在中心，左右基本对称」的视觉效果。

chart.setOption({ geo: { map: 'world', roam: true, layoutCenter: ['50%', '50%'], // 把地图放在容器正中间 layoutSize: '130%', // 让地图放大到容器宽度的 1.3 倍 center: [110, 30], // 中心放在中国附近，让中国靠中间 zoom: 1.2, boundaryGap: [10, 10], label: { show: false }, itemStyle: { areaColor: '#1e2b3c', borderColor: '#4a6785', borderWidth: 0.6 }, emphasis: { itemStyle: { areaColor: '#2a4a6b' } } } });

在这份配置里 layoutCenter 决定地图在容器中的锚点位置，layoutSize 决定地图整体在容器里占据多大面积，center 和 zoom 继续控制最终的视野细节。注意 layoutSize 和 zoom 同时设置时，ECharts 会按照 layoutSize 先缩放一次，再按 zoom 放大，最终效果是两者的乘积。所以如果你发现地图太大或太小，优先改 layoutSize，zoom 用来做交互时的临时缩放。

3.3 让地图不只是显示：series-map 和 geo 的差异与选型逻辑

ECharts 地图有两种实现路径：一是独立的 geo 组件，二是 series-map 系列。geo 组件适合只做底图展示、数据覆盖在其它坐标系上的场景，series-map 则自带数据映射和 visualMap 联动，适合直接用国家名称做数据匹配。标题里提到的是「以中国为中心的 world.js」，这个需求底下图展示场景居多，我推荐以 geo 组件为主，再用 series 里的 scatter 或 effectScatter 叠加标记点，而不是直接用 series-map，因为 series-map 的 center 配置和 geo 的 center 是独立的，两份配置都得写，维护成本高。

下面是叠加标记点的完整示例，其中 geo 只管底图，scatter 系列用 coordinateSystem: 'geo' 把数据点定位到地图上。

chart.setOption({ geo: { map: 'world', roam: true, layoutCenter: ['50%', '50%'], layoutSize: '135%', center: [110, 30], zoom: 1.1, itemStyle: { areaColor: '#122033', borderColor: '#3a5a80' } }, series: [ { name: '重点城市', type: 'effectScatter', coordinateSystem: 'geo', data: [ { name: '北京', value: [116.4, 39.9, 30] }, { name: '上海', value: [121.5, 31.2, 20] }, { name: '纽约', value: [-74.0, 40.7, 15] }, { name: '伦敦', value: [-0.1, 51.5, 10] } ], symbolSize: function(val) { return val[2] * 0.4; }, itemStyle: { color: '#f5c542' }, label: { show: true, formatter: '{b}', position: 'right' } } ] });

series 里的 data 每一项的 value 数组前两位必须是经纬度，因为用了 coordinateSystem: 'geo' 之后，ECharts 会自动把经纬度映射到 geo 坐标里。这里的 symbolSize 函数接收 value 数组并返回点的大小，val[2] 是第三个自定义数值。这套写法的好处是：你可以在其它不同坐标系里继续叠加别的 series，而底图只有一份，配置不会相互干扰。后面做 tooltip 联动时也只用挂在 geo 上的事件，不会出现 series-map 的事件重复触发。

4. 从地图到可交互大屏：tooltip、roam、visualMap 的联动设置

4.1 鼠标悬停与点击：geo 上的 tooltip 和事件绑定

地图能显示只是第一步，大屏场景里用户一定会悬停、点击。geo 组件默认自带 emphasis 高亮效果，但 tooltip 需要额外配置，因为在 ECharts 5 里 geo 组件的 tooltip 默认是不开启的。我一般把 tooltip 放到全局配置里，然后通过 formatter 区分当前悬停的是哪个国家。

chart.setOption({ tooltip: { trigger: 'item', // geo 上用 item 触发 backgroundColor: 'rgba(0,0,0,0.75)', borderColor: '#2aa1af', textStyle: { color: '#e6f7ff', fontSize: 13 }, formatter: function(params) { if (params.componentType === 'geo') { return `${params.name}<br/>点击查看详情`; } if (params.seriesType === 'effectScatter') { return `${params.name}<br/>数值：${params.value[2]}`; } return ''; } }, geo: { map: 'world', roam: true, ... } });

formatter 里通过 params.componentType 来区分触发来源，这一步非常重要，因为当页面里同时存在 geo 和 series 时，同一个悬停点可能触发两个信息。params.name 是 GeoJSON 要素里 properties.name 的值，如果你下载的 world.js 是英文名，这里显示的就是英文。为了让中文用户看懂，你可以用 nameMap 做映射，或者直接在 GeoJSON 里改 name 字段，后面避坑章我会写具体做法。

点击事件绑定的监听方式也有讲究，event 名是 'click' 而不是 'geoClick'，然后通过 params.componentType 过滤，只处理 geo 底图上的点击。

4.2 用 visualMap 做数据着色：连续数据与分段数据的两种写法

当你想表达每个国家的数值高低时，视觉映射组件 visualMap 是标配。它有两种模式：continuous 连续型和 piecewise 分段型。连续型适合人口、GDP 这类渐进数据，分段型适合等级数据，比如「高、中、低」或「一级、二级、三级」。下面这段配置把国家和数值绑定到 series-map 上，同时用 visualMap 控制颜色深浅。

// 假设 mapData 是 [{ name: 'China', value: 140 }, { name: 'United States', value: 30 }] chart.setOption({ visualMap: { type: 'continuous', min: 0, max: 150, left: 20, bottom: 20, text: ['高', '低'], calculable: true, inRange: { color: ['#1c355e', '#2a6e9c', '#3ba0b0'] } }, series: [ { name: '国家数据', type: 'map', map: 'world', roam: true, data: mapData, label: { show: false }, itemStyle: { areaColor: '#1c355e', borderColor: '#4a6785' }, emphasis: { label: { show: true }, itemStyle: { areaColor: '#f5c542' } } } ] });

series-map 的 data 必须是一个对象数组，每个对象有 name 和 value，name 必须和 GeoJSON 里的国家名字完全一致，否则数值匹配不上。visualMap 的 max 设成 150 是我根据当前数据写的示例，实际项目里应该动态计算。如果你用的是 geo 组件而不是 series-map，则 visualMap 无法直接生效，因为 geo 不消费 series 的 data，需要把数据挂到一个 series-map 上覆盖 geo 的视觉，或者改用 geo 的 regions 属性逐个国家设置颜色。后一种方式性能更好，但代码量大，适合国家数量少的场景。

4.3 完整大屏地图的配置骨架：代码结构、更新策略与销毁细节

把上面的所有配置合起来，一个可交付的大屏地图模块通常会长这样。我用一个函数封装初始化逻辑，另外提供一个 updateData 方法用于后续数据刷新。

class WorldMap { constructor(containerId, geoJson) { this.chart = echarts.init(document.getElementById(containerId)); echarts.registerMap('world', geoJson); this.baseOption = { ... }; // 第 3 章与 4.1 中的公共配置 } updateData(mapData, extraScatterData) { this.chart.setOption({ series: [ { name: '国家数据', type: 'map', map: 'world', data: mapData }, { name: '重点城市', type: 'effectScatter', coordinateSystem: 'geo', data: extraScatterData } ], visualMap: { min: 0, max: this.maxValue(mapData) } }); } maxValue(arr) { return arr.reduce((max, item) => Math.max(max, item.value), 0); } dispose() { this.chart.dispose(); } }

这里把 baseOption 放在构造函数里是因为地图底图配置不需要频繁更新，setOption 时只需要传入变化的部分。ECharts 会自动 merge 新旧配置，所以数据刷新不会导致 geo 被重建，也就不会出现地图闪烁。如果每次刷新都把完整配置丢进去，地图会经历一次重建，视觉上能明显看到闪烁，这个坑后面细说。

5. 避坑指南：地图居中、名字错位与闪烁的排查记录

5.1 坑一：地图居中只有半边，右边全是大海

现象：运行代码后中国在中间靠左，但整个地图的右半边全是空白，没有陆地。 原因：你用的是 0 到 360 的原始数据，但配置里却用了 -180 到 180 世界坐标系的 center，导致视野中心在经度 20 附近，可数据范围却从 0 到 360，右半边的陆地被推出了可视区域。 解决：先用控制台脚本检查坐标范围，如果是 0 到 360，把 center 先设成 [200, 30] 试试，或者直接改用 layoutCenter 作为主要居中手段，把地图放在容器正中间，再依情况微调 zoom。

5.2 坑二：地图上国家名全是英文，中文大屏没法看

现象：tooltip 里显示的是 China、United States，和页面上的中文标题明显不搭。 原因：下载的 world.js 里 properties.name 是英文，ECharts 不会自动翻译。 解决：有两个方案，一是利用 ECharts 的 nameMap 做全局映射，二是直接改 GeoJSON 里的 name 字段。项目里我推荐第二个，因为一劳永逸。写一段 Node 脚本，读入 GeoJSON，维护一个中英文对照表，把 features 里的 name 改成对应的中文名，脚本只有几十行，而且是纯文本替换，不容易出错。

const fs = require('fs'); const mapData = JSON.parse(fs.readFileSync('./world-centered.json', 'utf-8')); const nameMap = { 'China': '中国', 'United States': '美国', 'Russia': '俄罗斯', // ... 你需要维护完整的国家清单 }; mapData.features.forEach(feature => { const enName = feature.properties.name; if (nameMap[enName]) { feature.properties.name = nameMap[enName]; } }); fs.writeFileSync('./world-zh.json', JSON.stringify(mapData));

改完 name 后，series-map 的 data 里 name 也要同步改成中文，否则匹配失败，地图显示空白。这一步很容易忽略，我也踩过。另外如果你只有少部分国家要翻译，可以在 geo 配置里加 nameMap，ECharts 官方支持，写法是nameMap: { 'China': '中国' }，优先级高于数据里的原始 name。

5.3 坑三：世界地图闪烁/抖动，刷新数据时尤其明显

现象：setOption 更新数据时，整个地图先消失再出现，或者边界线不停抖动。 原因：最常见的是每次 setOption 都传入了完整的地图配置和 GeoJSON 数据，导致 ECharts 重建了整个 geo 组件；另一个原因是 geo 的 roam 开启时，ECharts 会响应 resize，数据更新触发了重新布局。 解决：把不变化的 geo 配置提取到一个对象里，在初始化时 setOption 一次，之后只用它做数据更新，传入的 option 只包含变化的 series 和 visualMap，并开启notMerge为 false 的默认合并行为。每次更新前还可以用chart.clear()确认是否真的需要重绘，不要无脑调用。

// 正确示范：初始只设置底图 chart.setOption(baseOption); // 后续更新只设置数据 chart.setOption({ series: [{ ..., data: newData }], visualMap: { ..., max: newMax } });

如果闪烁问题仍未解决，检查数据里是否有 null 或 undefined 值，ECharts 遇到脏数据时 react 渲染可能会触发地图重绘。把数据过滤一遍再传，通常能消除抖动。

5.4 坑四：地图加载慢，首屏白屏时间长

现象：同样一个地图，别人预览秒开，自己项目里要转圈好几秒，甚至卡死浏览器。 原因：你有意无意地用了体积很大的世界地图 GeoJSON，可能是几 MB 甚至十几 MB。ECharts 绘制这种数据时，canvas 需要绘制几十万个多边形顶点，帧率会暴跌。 解决：换一个轻量级的 GeoJSON 数据源，或者对现有 GeoJSON 做坐标抽稀。地图数据在精度要求不高时，虽然细节少了但肉眼差别不大。ECharts 项目里我一般用 topojson 格式加echarts-map的对应插件，体积能减小到原来的五分之一，加载速度提升明显。另一个办法是使用Regions属性只保留需要的国家数据，但如果你要展示世界全图就不能这么做，所以更通用的方案还是抽稀。

5.5 坑五：地图边界显示异常，北美洲有一根线横跨地图

现象：北美洲或俄罗斯区域出现一条从左边界通到右边界的线，多边形被拉成奇怪形状。 原因：数据源跨 180 度经线，但因为坐标范围转换时没有做多边形的拆分，导致多边形首尾两点跨越整个地图宽度，画出来的线作为多边形的边被渲染出来。 解决：用 2.4 节那个转换脚本时，要对跨 180 度线的多边形做拆分。网上有现成的 GeoJSON 拆分库，multiworld 之类的，但在生产环境里我更建议直接用已经处理好跨线问题的 world.js，比如 ECharts 官方 GitHub 仓库里的 world.json（它的坐标范围就是 -180 到 180）。省去自己处理跨线问题的麻烦。这是我这几年的血泪经验，地图数据从源头选好，后面能省一整晚。

6. 进阶技巧：把 world.js 变成高性能、可验证的交付物

到这一步，你已经能跑通一张以中国为中心的世界地图了，但离「可交付」还有两件事要完善：验证地图居中的客观指标，以及处理大屏场景下的长文本和数据性能问题。先说验证：不要只靠肉眼判断，在控制台里调用 convertToPixel 把中国某个城市的经纬度转换成屏幕坐标，看它是否落在容器横向中线上。

const point = chart.convertToPixel({ geoIndex: 0 }, [105, 35]); const container = document.getElementById('mapContainer'); const centerX = container.clientWidth / 2; console.log('中国中部像素坐标:', point); console.log('容器中心X:', centerX);

如果 point[0] 接近 centerX，说明中国确实在视野中间。这个方法比肉眼可靠得多，也方便后续做自动化截图验证。实际项目里我把这个检查封装成一个函数，每次调整配置后跑一次，确认没偏。

关于大屏场景下的性能，你会发现世界地图的边界本身只是一层静态图形，真正消耗性能的是叠加在上面的标记点、飞线动画和大量文字标签。如果页面上还有 markdown-it 渲染的长文本、表格等模块，地图的 resize 和重绘会被这些 DOM 操作拖累，导致交互卡顿。我的习惯是：把地图初始化和数据请求放在页面主流程之外，用 requestIdleCallback 延迟初始化，确保首屏优先展示内容；地图内部的动画只保留必要的，比如 effectScatter 的 rippleEffect 动画，其它非交互型的动画一律关闭。

最后说一个我自己的习惯：地图文件一定要和业务代码分开维护。world.js 或者 world-centered.js 属于静态资源，永远不应该被业务逻辑污染。每次接新项目，我都是先复制这个静态文件，再写一份检查脚本放到项目 scripts 目录里，验证坐标范围和 name 字段，确保换环境后地图表现一致。这样处理之后，不管是大屏还是后台管理页面，世界地图相关的问题都能在十分钟内定位到是数据问题还是配置问题，而不是漫无目的地查代码。希望这些办法能帮到你少走弯路，把时间留给真正值得做的业务逻辑。

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