简介一套覆盖全球各国的GeoJSON地图数据集合特别适合前端地图开发、GIS数据处理、数据可视化及地理教学等场景。无论是需要在网页中快速展示世界地图、开发带有国家边界的交互式图表还是进行区域统计分析这份以JSON/GeoJSON为核心的数据包都能提供开箱即用的基础地理数据免去从零抓取和整理的繁琐过程。压缩包整体约2.1MB共包含2000个文件其中绝大多数是JSON格式的GeoJSON数据既有countries.geo.json这类合并好的全球总文件也有按国家或地区单独拆分的AK、CAN、RUS、USA等子文件结构清晰便于按需调用。目前已有4731人学习浏览过该资源数据经过整理可直接配合Leaflet、Mapbox GL JS等主流地图库使用也可基于Properties字段进行面积计算、国家筛选等空间分析还可用于开发离线地图应用或作为GIS教学素材。文件命名规范、格式标准能显著降低地理信息处理中数据获取与预处理的成本对入门者和进阶开发者都是实用基础资源。1. 世界地图GeoJSON到底值不值得自己找一次可视化项目的数据起点做全球数据可视化面板的第一件事不是对比图表库而是找到能画地图的边界数据。我自己第一次做“世界地图”时光找“世界国家geojson”就花了半天——搜出来一堆“各国地图json数据”下载包有的大得离谱有的打开只有一块大陆更别提边界线跟实际差出好几个像素这直接决定了后面所有可视化效果能不能立住。这个标题看着简单背后牵扯数据精度、字段规范、坐标顺序和前端性能四个层次任何一个没处理好都得返工。这篇笔记就沿着这个标题把数据怎么选、结构怎么读、项目怎么落地、坑在哪儿一次讲透适合准备做全球业务看板、疫情分布图、出口贸易地图的开发者和数据分析师。2. 数据从哪来最省事先比数据形态再谈落地精度2.1 明确数据用途展示型和交互型的选型标准不一样在下载任何 GeoJSON 之前我会先问自己一个问题这份地图是拿来做静态展示还是要支持按国家高亮、点击、筛选这些交互这两类需求对数据的要求完全不同。静态展示图通常只需要一张世界轮廓图重点是国家边界清楚、配色舒服、加载够快。这时候用低精度的简化数据反而更合适因为在远视角下高精度数据带来的密密麻麻顶点根本显示不出来纯属浪费内存。但如果你是做交互型地图支持用户点击某个国家弹出该国数据或者按区域进行聚合分析那数据里就必须有可靠的标识字段比如 ISO 国家代码或者稳定的中文名不能只靠一个 display_name 字符串充当主键。另外还有一种分析型用法例如把多个国家合并成“东南亚区域”或者“欧洲区域”再做聚合计算。这种场景对数据边界连续性的要求就更高了国家与国家之间如果存在缝隙或者重叠前端渲染时会出现细白线或遮罩异常。这一步想清楚后面数据处理脚本的写法会完全不一样。2.2 主流数据形态对比单独大文件还是按国家拆分市面上的世界地图数据从文件组织方式上看基本可以分成下面几类。我不直接提具体站点但给出判断标准你按这个标准去找就行。数据形态典型场景精度水平体积体感常见问题单文件全量世界地图快速原型、飞线图底图低到中10MB 上下边界细节少国家名缺失按洲拆分的大区块文件区域大屏展示中单文件 1-5MB洲内国家边界合并逻辑混乱按国家拆分的 json 分片点击高亮、按需加载高单国几十到几百KB文件过多需要自己管理索引Shapefile 转出来的 GeoJSON专业地理分析高顶点数巨大字段名不规范坐标易出错在线矢量瓦片服务大数据量在线地图高按需切片依赖网络离线场景不适用我一般优先选择“按国家拆分”的数据包。原因是前端可以按需加载用户视角只在亚洲区域时就没有必要把整个非洲的坐标塞进内存。另一个判断标准是看这份数据的更新时间如果仓库上一次提交已经是两三年前甚至更早我会谨慎用因为国界数据是有时效性的某些地区的归属可能在近几年有调整坐在一个旧版底图上做业务展示很容易在内部评审环节被质疑。2.3 下载前检查三件事字段、坐标边界、数据完整性拿到任何一个压缩包先别急着解压扔进项目里先用命令行做三件最基础的检查。我能理解大家想快点看到效果但这一步省掉后面翻车概率直接翻倍。第一件是看文件里有没有 properties 字段并且里面的键名是否统一。有的数据包把国家名放在 properties.name有的放在 properties.NAME还有的干脆只有 id 没有名称。两种字段风格混在同一个文件里的情况也不少见。第二件是看坐标数值的范围GeoJSON 用的坐标系绝大多数是 EPSG:4326也就是经纬度经度范围是 -180 到 180纬度范围是 -90 到 90。如果你发现某个 feature 的坐标里出现了 30 到 60 这种范围、和经纬度感觉对不上那就说明这份数据被转换过坐标参考系直接拿来前端渲染会错得莫名其妙。第三件是检查数据完整度。可以参考一个非常朴素的清单文件里是否包含了 190 多个左右的国家和地区中国地图数据的边界是否完整每一个国家的 geometry 是否为 Polygon 或 MultiPolygon 类型。脚本随手就能写比如说用 jq 命令统计一下类型分布看看除了 Polygon 以外是不是混进了奇怪的 GeometryCollectionjq .features[] | .geometry.type countries-all.json | sort | uniq -c这段命令的作用是把每个 feature 的几何类型打印出来然后归类计数。正常情况你应该只看到 Polygon 和 MultiPolygon 两种如果出现了 GeometryCollection 或者 LineString说明这份数据的生成方式有问题渲染时地图库可能无法识别。jq 是处理 JSON 的常用工具如果系统里没装也可以用 Node.js 的 JSON.parse 配合循环统计效果一样。下载阶段花十分钟做这三个检查能省下后面几小时排查渲染异常的功夫。3. 读透GeoJSON结构坐标顺序、字段约定和合并逻辑3.1 FeatureCollection 里到底放的是什么GeoJSON 本质上是一种 JSON 文本格式它不挑编程语言任何能解析 JSON 的环境都能直接处理。最外层通常是一个 FeatureCollection里面是一个 features 数组数组里每一个元素都是一个 Feature。每一个 Feature 由两部分核心内容构成geometry 描述坐标形状properties 描述业务属性。下面这个例子是我从一份通用数据包里截取并精简后的结构足以说明问题{ type: FeatureCollection, features: [ { type: Feature, properties: { iso_a2: JP, name: Japan, name_zh: 日本 }, geometry: { type: MultiPolygon, coordinates: [ [ [ [131.0, 33.2], [131.4, 33.4] ] ] ] } } ] }这段结构里features 数组的每个元素代表一个国家或地区。properties 里的 iso_a2 是国际通行的两位国家代码name 是英文名name_zh 是中文名这三个字段在做跨语言切换时非常有用。geometry 里的 coordinates 是一层套一层的地理坐标点数组。为什么会有这么多层嵌套因为一个国家的地图边界不可能是光滑的每一条边界都是由成百上千个坐标点连接而成而一个国家的领土可能包含多个不相连的区块比如岛屿和本土因此需要用多重数组来表示这种“多个区域”的情况。理解了这一层嵌套你就知道为什么不能简单粗暴地把多个文件的 coordinates 拼接在一起了。合并国家数据时要保证每个 feature 仍然是一个完整的 Feature 对象而不是把不同国家的坐标点塞进同一个坐标数组里那样地图渲染时会画出一条连接两个国家的怪异长线。3.2 经度在前坐标顺序这条硬规则为什么不能改GeoJSON 规范里明确约定了坐标顺序是 [经度, 纬度]也就是先写左右方向、再写上下方向。很多新手在这一步会犯错是因为平时口语里常说“经纬度”惯性以为 JSON 数据里也是纬度在前结果渲染出来的地图整体旋转、区域错位看起来像进了镜面世界。我用最简单的方式记忆看一个坐标点[116.4, 39.9] 这个数值范围就能帮你判断116 这样的数值属于经度范围39 这样的数值属于纬度范围。所以当你发现一个 GeoJSON 文件里的坐标点普遍都在 -90 到 90 之间而不是 -180 到 180 之间那大概率这个文件被某个转换工具调换了坐标顺序或者原始数据本身不符合规范。还有一个常见变体叫 GeoJSON 中嵌套的坐标会出现类似 [39.9, 116.4, 0] 的三维数组多出来的第三个数值是海拔有些转换工具会保留大多数地图库会忽略它。但为了避免混淆我建议写数据处理脚本时主动把多余的维度清理掉只保留经纬度两个值让最终文件保持干净一致。3.3 properties 里该有什么从“能用”到“好维护”的字段规范一份能用的 GeoJSON 只需要坐标正确即可但一份好维护的 GeoJSON 离不开稳定的属性字段。我经手过的数据包里同一份数据可能混着几种命名风格有的用 name有的用 NAME有的用 name_zh有的就只有一个数字 id。前端组件如果依赖固定字段名那就要加工再使用。我一般会在数据清洗阶段统一字段规范固定保留下面这些字段名示例值用途是否必须id156内部主键必须iso_a2CN两位国际代码用于匹配业务数据强烈建议iso_a3CHN三位国际代码用于后端数据关联视业务而定nameChina英文名称用于默认展示建议保留name_zh中国中文名称用于中文界面建议保留continentAsia大洲归属用于区域筛选可选为什么要尽量保留 iso_a2 这一列因为在真实的业务场景中后端返回的数据通常也是通过国家代码关联的例如某个销售表格里填的是“CN”而不是“中国”前端拿到地图数据和业务数据之后必须有一个稳定的关联键把两份数据 join 起来。如果你只依赖中文名做键遇到“老挝”和“寮国”这种称呼差异就会开始头疼。稳定代码在数据整理阶段花十分钟保留好是成本最低的“后悔药”。4. 把各国json数据喂进项目加工、按需加载与样式参数4.1 先加工再发布用脚本清理字段、统一主键下载到的原始数据往往直接可用但离“项目级数据”还有一段距离。我的习惯是先跑一个 Node.js 脚本把分散的国家分片文件合并成一个精简版 FeatureCollection同时只保留需要的字段这样输出的数据包体积能缩小一半以上也方便前端一次请求加载。下面这个脚本是比较通用的做法假设原始数据已经解压到 raw/countries 目录const fs require(fs); const path require(path); const RAW_DIR path.join(__dirname, raw, countries); const OUT_FILE path.join(__dirname, public, geo, world-slim.geojson); const features []; const files fs.readdirSync(RAW_DIR).filter(f f.endsWith(.json)); for (const file of files) { const raw JSON.parse(fs.readFileSync(path.join(RAW_DIR, file), utf-8)); const feature raw.type FeatureCollection ? raw.features[0] : raw; if (!feature || !feature.geometry) continue; const props feature.properties || {}; const cleaned { type: Feature, properties: { id: props.id || props.iso_a3 || file.replace(.json, ), iso_a2: props.iso_a2 || props.iso2 || , iso_a3: props.iso_a3 || props.iso3 || , name: props.name || props.NAME || , name_zh: props.name_zh || props.CN_NAME || }, geometry: feature.geometry }; features.push(cleaned); } const collection { type: FeatureCollection, features: features }; fs.writeFileSync(OUT_FILE, JSON.stringify(collection)); console.log(done: ${features.length} countries - ${OUT_FILE});这段脚本的逻辑并不复杂遍历目录下每个 JSON 文件如果文件本身是 FeatureCollection 就取第一个 Feature如果是单个 Feature 就直接使用然后从原属性里按优先级顺序提取 id、iso_a2、iso_a3 等字段最后统一写入一个 FeatureCollection 文件。这里的关键参数是字段提取的兜底顺序比如props.iso_a3 || file.replace(.json, )的意思是如果原始数据里没有三位国家代码就把文件名当作 id。这个兜底策略在数据字段不统一时特别管用能保证输出的每个 feature 至少拥有一个稳定主键。这段脚本之后可以扩展例如在循环里统计 name 为空的 feature 数量并把它们单独打印出来方便你快速发现哪些国家的数据缺少关键字段。建议把这个脚本保留在项目的 scripts 目录下每次拿到更新版原始数据就重跑一次形成固定的数据加工流程。4.2 前端最小加载按需读取国家分片如果项目需要的是世界全图直接用上面生成的 world-slim.geojson 即可。但如果页面只关心亚洲区域或者希望点击某个大洲再展开国家数据那更推荐使用“按国家拆分”的加载方式。以地图库的通用加载模式为例先请求一个大洲级别的极简轮廓等用户点击后再按需加载对应国家的详细边界 JSON 数据。这种分层加载策略能显著提升首屏速度。下面是一段示意代码展示如何在一个前端地图组件中加载 GeoJSON 并绑定点击事件script srchttps://unpkg.com/leaflet1.9.4/dist/leaflet.js/script link relstylesheet hrefhttps://unpkg.com/leaflet1.9.4/dist/leaflet.css / div idmap/divconst map L.map(map).setView([25, 105], 3); L.tileLayer(https://{s}.tile.openstreetmap.org/{z}/{x}/{y}.png, { maxZoom: 8 }).addTo(map); const loadCountry async (countryId) { const res await fetch(/geo/countries/${countryId}.json); const data await res.json(); return data; }; const onCountryClick async (e) { const country e.target.feature; const detail await loadCountry(country.properties.id); L.geoJSON(detail, { style: { color: #fbbf24, weight: 2, fillColor: #f59e0b, fillOpacity: 0.3 } }).addTo(map); }; fetch(/geo/world-outline.geojson) .then(res res.json()) .then(outline { L.geoJSON(outline, { style: { color: #64748b, weight: 1, fill: false }, onEachFeature: (feature, layer) { layer.on(click, onCountryClick); } }).addTo(map); });这段代码里有一个值得留意的设计世界轮廓用极简 outline 数据保证首次请求飞快点击后再用主键 id 拼出具体国家的文件路径加载详细边界并渲染到地图上。这样既保住了交互效果又避免了首屏加载 10MB 全量数据的尴尬。Leaflet 中onEachFeature是给每个地图要素绑定事件的入口你在开发时可以在这里加上 hover 效果例如鼠标移过时改变透明度。需要留意的是第二次点击同一个国家时页面会叠加一个重复图层所以在加载国家详情前先判断该 countryId 是否已经渲染过再决定是移除旧图层还是直接复用。4.3 渲染时最值得调的三个参数抽稀阈值、边界样式、中文标注数据加载进来了画出来的效果却不理想这种情况通常是渲染样式参数没有调到位。我在实际项目里最常调的是下面三个参数它们直接影响视觉观感和性能。第一是抽稀阈值也就是坐标点的简化比例。原始数据里一个国家可能包含十几万个坐标点但地图缩小到全国视野时根本不需要这么多细节。常见的方案是在数据预处理阶段用简化算法把顶点数量压缩到原来的 10% 到 20%。这个比例没有固定值全靠肉眼判断在目标缩放级别下边界线仍然平滑、国界形状不失真即可。第二是边界线的 stroke 宽度和颜色。静态展示场景下国界线的颜色应该弱于业务数据本身我一般会把国界线的 weight 设为 0.5 到 1颜色选灰蓝色系看起来像一张专业的底图。交互场景下hover 和点击态的颜色要对比鲜明例如底图灰白、高亮填充金橙色形成一个清晰的视觉层级。第三是中文名称标注。GeoJSON 本身不含标注信息地图库通常有两种方案一种是使用 map 的 label 插件把 properties.name_zh 渲染成文本图层另一种是直接把名称写到 properties 里用前端框架的 Marker 组件挂载。推荐第一种因为文本图层会随缩放级别自动避让和隐藏避免名字挤成一团。没有中文字段的数据包可以在数据加工阶段用批量翻译脚本补上这一步做得越早后面做运营后台时越轻松。4.4 一个常见误区别在前端实时加工数据有些开发者图省事把原始数据直接扔给前端然后写一堆 JavaScript 在前端循环加工字段。对于只跑一次的小 Demo 没问题但在正式项目里这份加工工作应该下沉到数据准备阶段。原因是前端脚本的调试成本远高于 Node 脚本前端没有直观的文件输出字段出错时很难定位问题而且每次页面加载都要重复跑加工逻辑浪费宝贵的主线程时间。我通常会把数据加工和前端渲染彻底分离开加工脚本输出什么前端就原样用什么。前端代码因此可以写得非常干净几乎不需要处理“这个国家没有 name 怎么办”这类边界 case。如果你接手了一个已经把加工逻辑写在前端的项目我的建议是尽快把它重构成独立的预处理脚本这不仅让接口数据更可控也为后续数据更新打好了基础。5. 地图数据落地避坑五个必须提前处理的边界问题5.1 国界数据不合法合规页面做出来都不敢上线现象地图底图中国家边界画错或者漏了关键地区被业务方指出来紧急下架。原因很多直接从网上随手扒下来的 GeoJSON 数据包原始出处不明边界精度和归属处理不严谨。部分数据甚至带着明显的手工修改痕迹边界线和官方公布的不一致。解决只要涉及正式项目国界数据必须以官方发布的信息为准去官方渠道或可信的开源地图仓库获取并且保留来源记录备查。不要自己手工编辑边界不要用标注工具去“微调”国界线。任何从第三方站点下载的数据上线前要做合规检查拿不准时宁可不做该区域也不要带病上线。5.2 经纬度顺序写反渲染出来的地图整个镜像错位现象地图上的每个国家形状还在但位置整体偏了有的国家跑到海里有的国家横向颠倒。原因GeoJSON 规范要求坐标是经度在前、纬度在后。数据生成工具如果不是按规范输出的或者有人工手动修改坐标时写反了就会出现这类问题。解决加载数据后先看几个已知坐标点是否落在正确位置。以某个熟悉位置为例经度大约 116、纬度大约 40如果你在数据里看到的是 40、116 这样说明坐标顺序需要翻转。写一个简单的批量脚本遍历所有坐标点把每个数组的前两个值交换并重新输出即可。这个脚本执行前注意先备份原始文件。5.3 下载的数据里国家名全是代码前端展示没法看现象地图渲染出来了但 hover 时提示框里显示的是 CN、JP、US 这类字母而不是中文国名。原因数据提供方为了追求精简properties 里只放了 ISO 代码没有放显示名称。甚至有些数据把名称放在了一个不明显的字段里比如 NAME_CN、zh-name。解决在数据加工阶段统一字段名称。如果原始数据实在只有 ISO 代码可以维护一份由代码到中文名的映射表在预处理脚本里做一次 join把 name_zh 字段补齐。这个问题越早处理越好因为等地图做完了再补名称就得重新过一遍数据发布流程。5.4 全量数据文件过大页面加载时直接卡死现象首次打开页面要等很久地图转圈浏览器有卡顿甚至无响应。原因一份未经验收的原始世界地图 GeoJSON 可能有几十 MB包含上千万个坐标点。浏览器要解析这么大的 JSON再交给地图库绘制大量图层性能和内存双双扛不住。解决核心思路是“能少就别多”。首屏加载只给极简轮廓数据点击到具体国家时再加载精细数据如果业务上必须一次加载全图就在预处理阶段做坐标抽稀把数据体积压到可接受范围内。实际经验里抽稀后的世界全图数据控制在 1MB 左右交互体验和视觉精度的平衡比较理想。注意抽稀不是把每个坐标点隔一个删一个那样边界会拉出奇怪的直线条需要用专用的简化算法简化的核心思想是丢弃对形状影响最小的点。5.5 多国数据合并后留下内部边界点击区域重叠粘连现象把多个国家合并成一个自定义区域后区域内部还能看到原来的国界而且点击某个国家时高亮区域会挡住旁边国家。原因合并操作只做了“把多个 Feature 放进一个集合”没有真正合并它们的 geometry。内部边界线还在几何体之间互相重叠事件响应就会混乱。解决如果不需要保留内部边界就使用集合求并集的操作把多个国家的 Polygon 合并成一个完整的 MultiPolygon这样内部边界线和重叠区域都会被消除。需要说明的是这个操作计算量不小适合在预处理脚本里跑一次而不是放在前端实时执行。合并后的数据同样要检查属性字段因为一个自定义区域的身份应该是一整个新对象不再是某单一国家的属性。6. 进阶技巧把多个国家合并成自定义区域并跑通增量更新多国合并这个需求比想象中常见运营后台要按大洲统计销量大屏要展示“亚洲区域数据”而数据源里只有单个国家的 GeoJSON。手动处理这些问题并不愉快写个脚本才是长久之计。以“把东南亚十国合并为一个自定义区域”为例我会拿一份按国家拆分的 GeoJSON 数据筛选出属于该区域的所有国家然后执行几何求并集操作。Turf.js 提供了一个做并集计算的 API叫做 union它能把多个多边形合成一个整体。注意它的调用方式是对两个要素依次两两合并而不是一次传入全部要素。脚本大致长这样const fs require(fs); const path require(path); const turf require(turf/turf); const countryIds [TH, MY, SG, ID, PH, VN, KH, LA, MM, BN]; const baseDir path.join(__dirname, raw, countries); let merged null; for (const id of countryIds) { const raw JSON.parse(fs.readFileSync(path.join(baseDir, ${id}.json), utf-8)); const feature raw.type FeatureCollection ? raw.features[0] : raw; if (!merged) { merged feature; } else { merged turf.union(merged, feature); } } const output { type: FeatureCollection, features: [{ type: Feature, properties: { id: SEA, name: Southeast Asia, name_zh: 东南亚 }, geometry: merged.geometry }] }; fs.writeFileSync( path.join(__dirname, public, geo, region-sea.geojson), JSON.stringify(output) );这段脚本有几个值得注意的细节。第一个是 union 必须传入完整 Feature 对象不能只传 geometry否则拓扑计算时容易丢失属性上下文。第二个是处理顺序会对结果有影响一般建议先从地理位置居中的国家开始合并再向周围扩展能减少计算过程中出现的异常几何。第三个是合并完成后务必检查 geometry 的类型有的国家并集结果是 Polygon有的结果会变成 MultiPolygon前端样式对这两种类型都要能兼容。增量更新的思路也很容易落到这套脚本里原始数据仓库每次更新时重新跑一次全流程脚本就可以。我会把脚本拆成三步verify 校验原始数据完整性build 生成世界精简数据merge 生成自定义区域数据。每次更新后顺手跑一遍整个流程不超过一分钟。这种把数据加工完全脚本化的习惯帮我在多个项目中省了大量重复劳动也让我自己不再担心“数据后续到底维护不维护”这类问题。最后分享一个土办法拿到任何新数据包我第一步总是打印出它的配置文件里所有国家 id 数量、字段名和坐标范围三行信息全打出来确认没问题才继续往下走。这个习惯让很多潜在问题在源头就被截住了。每个人的使用场景和数据源不一样但只要你选对了数据结构、坚持在预处理阶段做好规范这门技术完全能稳稳落地。希望帮到你。本文还有配套的精品资源点击获取