GeoJSON完全指南：从QGIS数据处理到Web前端应用实战

做GIS和Web开发的人应该都经历过这种场面后端辛辛苦苦整理了一份Shapefile前端同事拿到手直接懵了——浏览器根本读不了那个shp二进制包。后来大家慢慢形成了默契矢量数据交换统一用GeoJSON。一个带.geojson后缀、用记事本打开全是文字的文件前端拿到手直接就能解析中间省了多少破事。今天这篇《QGIS快速入门与应用基础》第074篇就把GeoJSON这件事说透它是怎么组织的、在QGIS里怎么处理、最终怎么交给Web端用起来以及我在实际项目里踩过的那些坑。这篇内容不只适合正在学QGIS的小白也适合桌面GIS和WebGIS两边都要沾的工程师。你不需要先懂JSON我会从最基础的文本结构讲起一点点拆到你敢在实际项目里直接用GeoJSON对接前后端。1. GeoJSON的本质与结构为什么它是Web端的“通用语言”GeoJSON不是什么高深的东西它的全称就是“地理JSON”本质上是一种基于JSONJavaScript Object Notation的地理空间数据编码格式。2016年它正式成为RFC 7946标准从那以后基本就是Web端矢量数据交换的事实标准了。为什么它能火因为它用纯文本的方式描述几何对象、属性信息和空间关系跟JavaScript天然兼容浏览器里一句JSON.parse就能把整个地理数据变成可操作的对象这在以前用XML的GML、KML时代是没法想象的。一个GeoJSON文件打开后你看到的不是乱码而是一长串结构清晰的文本。它由对象、数组、数字、字符串等基础类型组成用一对大括号把整个数据包起来。最外层通常是一个FeatureCollection要素集合对象里面包含一个type字段值为FeatureCollection再加一个features数组数组里每一个元素就是一个Feature要素。每个要素又包含它的几何信息geometry和属性信息properties。这种一层套一层的结构跟你在数据库里看到的“一张表一行记录”很像几何信息是那一行的空间位置属性信息是那一行的业务字段。我见过不少第一次接触的人被那一大串嵌套的括号吓住其实拆开看就四个关键词FeatureCollection、Feature、geometry、properties。只要你能在这四层之间来回切换GeoJSON你就算入门了。1.1 一句话说清GeoJSON是什么GeoJSON是一种开放标准的地理空间数据交换格式以JSON文本为载体用来描述点、线、面等地理要素以及它们的属性信息。它的应用场景覆盖了Web地图、移动App、数据可视化工具、GIS软件交互等几乎所有需要跨系统传递矢量数据的环节。你在Leaflet里加载一个点图层、在OpenLayers里绘制一个多边形、在ECharts里做带地图的数据图表背后大概率都是GeoJSON在跑。它最大的优势有三个。第一纯文本任何平台、任何语言都能读写不存在二进制格式的兼容问题第二结构自描述你拿到文件打开看一眼就能知道有哪些要素、哪些字段、每种要素的几何类型是什么第三基于Web标准JavaScript可以直接消费前后端联调的成本极低。我记得早年间做项目最怕的就是甲方扔过来一堆不是标准格式的数据用QGIS一个个转格式转到头大自从大家统一默认GeoJSON之后这类破事少了很多。1.2 数据长什么样从一个FeatureCollection看起我们直接看一个真实的GeoJSON片段感受一下它的结构。假设我们要记录三个公园的位置那么对应的GeoJSON大概是这样的{ type: FeatureCollection, name: parks, crs: { type: name, properties: { name: urn:ogc:def:crs:OGC:1.3:CRS84 } }, features: [ { type: Feature, properties: { id: 1, name: 人民公园, area: 12.5, open_time: 06:00-22:00 }, geometry: { type: Point, coordinates: [116.391, 39.907] } }, { type: Feature, properties: { id: 2, name: 湿地公园, area: 45.0, open_time: 全天 }, geometry: { type: Point, coordinates: [116.402, 39.916] } } ] }最外层type是FeatureCollection这是最常见的情况表示这是一个要素集合。features数组里每个对象都是一个完整的要素每个要素的geometry字段描述空间位置properties字段描述业务属性。上面这个例子里每个公园就是一个Point点用经纬度坐标表示位置旁边的name、area、open_time就是挂在点上的属性信息前端渲染的时候可以直接用这些字段做弹窗、做样式、做筛选非常方便。geometry的type字段支持多种几何类型Point点、MultiPoint多点、LineString线、MultiLineString多线、Polygon面、MultiPolygon多面还有GeometryCollection几何集合。每种类型对应的coordinates结构不同比如Point就是一个坐标对LineString是一个坐标对数组Polygon则是一个由线性环组成的数组第一个环是外环后面的环是内环相当于洞。QGIS里加载任何一种类型都能识别前端地图库也都能渲染只是样式逻辑上要区分处理。1.3 坐标系与坐标顺序最容易翻车的地方GeoJSON的官方标准强制规定所有坐标必须使用WGS84坐标系也就是EPSG:4326并且坐标顺序要按经度、纬度的顺序排列像[116.391, 39.907]这样数字代表东经116.391度、北纬39.907度。这个规定本身是为了统一规范但也是实际项目里最容易出问题的地方。我在项目里见过最典型的一个问题数据源本身是CGCS2000坐标系或者是投影坐标系比如高斯-克吕格投影直接在软件里导出了GeoJSON却没有做坐标转换前端拿到手所有要素位置全都跑到海里去了。还有一个更隐蔽的坑就是坐标顺序搞反。有些工具导出的坐标是[纬度, 经度]前端如果不做判断直接用Leaflet的L.geoJSON去渲染所有点会整体偏移看起来像数据错了其实是坐标顺序反了尤其在中国区域经纬度都在一百度左右反了之后位置偏差非常明显。注意判断一个GeoJSON文件坐标顺序靠不靠谱最快的办法是选一个你熟悉的地标看它的坐标值。以东经116、北纬39这种数值出现在文件里基本就是规范写法如果看到的是[39, 116]这种前小后大的组合十有八九就是顺序反了。2. QGIS打开与编辑GeoJSON比文本编辑器强太多GeoJSON本质是文本文件所以直接双击用记事本也能打开。但我不建议你那么干。几十万条数据堆在一个文件里用文本编辑器翻找简直是一场灾难眼睛看花不说想改一个坐标根本无从下手。正确姿势就是交给QGIS这类GIS软件来打开可视化浏览、编辑、查询、转换一步到位。这一节我具体讲讲在QGIS里处理GeoJSON的完整操作流程包括打开方式、属性表检查、符号化设置和编辑保存时的注意事项。2.1 QGIS打开GeoJSON的3种方式第一种最直接把.geojson文件从文件夹里拖到QGIS的图层区域松开鼠标QGIS自动识别并加载一旦加载成功图层面板里就会出现对应图层地图画布上也会渲染出要素。这种方式适合临时看个文件操作成本最低。第二种是通过菜单操作点击菜单栏的“图层” → “添加图层” → “添加矢量图层...”在弹出的对话框里数据源类型选择“文件”然后点击“...”按钮找到你的GeoJSON文件点击“添加”即可。这种方式适合需要精确控制文件编码、坐标系等参数的时候尤其是处理中文乱码问题用这种方式你可以在编码一项里手动指定UTF-8。第三种是使用浏览器面板。如果你打开了QGIS右侧的“浏览器”面板直接在里面定位到文件所在目录找到带有地球图标的GeoJSON文件双击或者拖拽到画布即可。这个方法在数据量很大的情况下我个人更推荐因为它是走标准的矢量图层加载通道比直接拖拽更稳定。2.2 属性表与符号化数据质量先看清文件加载进来之后不要急着往Web端扔先做两件事。第一件事是打开属性表在图层上右键选择“打开属性表”把所有字段过一遍看看字段名、字段类型、有无空值、有无乱码。很多时候你从别人手里拿到的GeoJSON属性字段名是中文的字段值是混着多余空格或者引号的这种数据不洗直接用前端展示的时候问题一抓一大把。第二件事是给图层做符号化。默认情况下QGIS会用随机颜色、单一符号把所有要素渲染成同一种样式。如果你想在地图上快速看每个要素之间的差异比如按面积大小分级着色可以在图层样式中选择“分类”或“渐变”用属性字段做分类依据。这一步不是纯粹为了好看它实际上是帮你做数据体检如果一个本该是点图层的文件里混进了面要素或者某个要素的几何类型变了在符号化的过程中很容易暴露出来。2.3 直接在QGIS里编辑GeoJSON的注意事项QGIS允许你直接对GeoJSON图层进行编辑点击“切换编辑模式”然后就能用编辑工具栏里的工具增加、删除、移动节点或者修改属性值。编辑完成后点保存按钮QGIS会直接把改动写回原文件。听起来很方便但这里有几个坑我必须提醒你。第一个坑是主键字段。QGIS在保存GeoJSON时会自动检查是否有唯一的标识字段。如果你的数据里没有合适的唯一值字段QGIS可能会自动生成一个类似id的字段有时还会因为这个字段类型不合适而保存失败。我建议在编辑之前先在属性表里确认一下是否有一个类型为整数、值唯一的字段如果没有提前加上一个序列字段再进入编辑能避免很多麻烦。第二个坑是编码。GeoJSON官方要求用UTF-8编码但QGIS在不同的操作系统、不同的文件来源下读取时对编码的检测偶尔会抽风。如果你的属性值里出现了中文乱码保存再导入前端之后乱码会跟着走前端根本没法用。遇到这种情况不要直接在原文件上改用“要素另存为”的方式在编码那里显式选择UTF-8输出一个新文件再把新文件作为后续操作的基础。第三个坑是编辑大文件。一个几十MB的GeoJSON文件编辑一次保存一次QGIS的响应速度会明显下降甚至卡到没响应。对于大数据量文件我一般不在GeoJSON直接编辑而是先导入到GeoPackage或者PostGIS里面做管理和编辑最后需要输出给前端时才导出成GeoJSON。GeoJSON更适合作为“交付格式”不太适合当“工作格式”。3. 格式转换与坐标系处理从传统数据到Web数据的一步到位实际工作中你手里拿到的原始数据经常不是GeoJSON。规划院给的是CAD的DWG测绘那边给的是Shapefile还有人甩给你一份带经纬度的Excel表格。这个时候QGIS就是你的格式中转站。把各种格式统一转成GeoJSON是这节要讲的核心内容。转换本身很简单但转换前后的坐标系处理才是关键很多人转出来的文件前端拿到显示位置不对九成是坐标系这一步出了问题。3.1 Shapefile、CAD、CSV转GeoJSON的标准流程以一个最常见的Shapefile转GeoJSON为例。在QGIS的图层列表中找到你的Shapefile图层右键点击选择“导出” → “要素另存为...”这时候会弹出导出对话框关键设置如下格式在下拉列表里选择“GeoJSON”文件名设置输出文件路径注意后缀写.geojsonCRS选择EPSG:4326WGS84编码选择UTF-8其他选项保持默认点击“确定”一个符合Web端要求的GeoJSON就生成了。整个流程不超过三十秒。如果是CSV表格转GeoJSON稍微特殊一点。你需要确保表格里有两个字段分别存着经度和纬度坐标然后用“图层” → “添加图层” → “添加分隔文本图层...”导入在导入对话框中指定X字段为经度、Y字段为纬度再设置好坐标系这样CSV就以点图层的形式加载到QGIS里了。之后的导出步骤就和上面一样右键导出为GeoJSON即可。如果是CAD的DWGQGIS不能直接读取DWG需要先用CAD软件或者转换工具把DWG转成DXF再用QGIS导入DXF之后按标准流程导出。CAD数据在转换时还有一个常见问题很多DWG的坐标值非常大比如几千几万这种坐标一看就是投影坐标系。你在导出GeoJSON之前必须先搞清楚源数据的坐标系是什么然后才能在导出时正确转换到EPSG:4326否则前端拿到坐标直接飘到外太空。3.2 CGCS2000、WGS84、Web Mercator导出时选对CRS关于坐标系这是国内GIS项目最容易产生困惑的地方。我们经常遇到三个坐标系WGS84EPSG:4326、CGCS2000EPSG:4490或者投影带如EPSG:4513、Web墨卡托EPSG:3857。WGS84是GPS卫星定位用的全球坐标系CGCS2000是我国2000国家大地坐标系这两个在绝大部分应用场景下精度差异可以忽略不计但因为定义基准略有不同严格来说属于两套体系。Web墨卡托则是目前所有在线地图底图如各种在线瓦片地图服务默认使用的投影坐标系它是把全球按墨卡托投影展开后的平面坐标。GeoJSON标准默认坐标系是EPSG:4326也就是WGS84经纬度。所以不管你源数据是什么坐标系导出GeoJSON时都应该把目标CRS设置成EPSG:4326。在QGIS导出对话框中CRS下拉框里搜索4326选中然后导出QGIS会帮你自动完成坐标转换。这里要特别说一下CGCS2000和WGS84在GeoJSON里的处理。很多新手拿到一套CGCS2000的高斯投影数据在QGIS里看到数据正常显示导出成GeoJSON后也不报错但前端加载之后要素位置明显偏移这是因为导出时没有做重投影直接保留了投影坐标值。正确的流程是在QGIS里设置工程CRS为CGCS2000对应的投影带让数据正常显示然后在导出GeoJSON时在CRS这里手动搜索并选择EPSG:4326让QGIS完成从投影坐标到地理坐标的转换。如果你拿到的原始文件本身已经带了正确的PRJ文件QGIS会自动识别源坐标系导出时你只管目标CRS选4326就行。还有一些场景前端要求用EPSG:3857的GeoJSON。严格来说这已经不符合GeoJSON标准了但某些地图库和工具为了性能需要确实会接受这种“坐标是Web墨卡托”的GeoJSON。如果你遇到的是这种需求导出时目标CRS选EPSG:3857即可但最好在前端代码里做说明避免后续维护的人踩坑。3.3 批量转换与字段精简一次处理多个文件如果手里有几十个Shapefile要一次性全部转成GeoJSON挨个右键导出会累死人。QGIS里的“处理”→“工具箱”可以解决这个问题。搜索“栅格/矢量转换”相关工具找到“导出要素”或“转换为GeoJSON”之类的处理算法以批处理模式运行选好所有输入图层和输出目录一次跑完。批量转换时我特别建议顺手做字段精简。原始数据里经常有一大堆用不到的属性字段比如测绘数据的内部编码、DWG导入时的图层名、多余的面积字段等。字段太多会直接拖累前端解析和渲染性能。QGIS里可以先在原始图层上做字段筛选在属性表中关闭不需要的字段或者用工具箱里的“按表达式提取”“删除字段”工具处理最后再导出GeoJSON。导出的文件里只保留前端真正需要的字段文件体积小一大截加载速度快得多。4. GeoJSON在Web端的应用落地从QGIS导出到前端加载前面做的所有工作最终目标都是为了让数据在Web端跑起来。这一节我从前端的角度讲讲怎么把QGIS导出的GeoJSON给用起来包括基础加载方式、部署时的注意事项和性能优化手段。这里我不会讲特别深的前端知识但会给出一套能直接跑的代码示例你照着改就能用。4.1 前端加载一个Leaflet示例目前主流的地图库不管是Leaflet、OpenLayers还是Mapbox GL JS都对GeoJSON提供了原生支持。以Leaflet为例加载一个GeoJSON文件的核心逻辑非常简洁// 初始化地图 const map L.map(map).setView([39.907, 116.391], 15); // 添加底图瓦片生产环境建议换成自己的瓦片服务 L.tileLayer(https://{s}.tile.openstreetmap.org/{z}/{x}/{y}.png, { maxZoom: 19, attribution: © OpenStreetMap contributors }).addTo(map); // 加载GeoJSON数据 fetch(data/parks.geojson) .then(res res.json()) .then(data { L.geoJSON(data, { pointToLayer: (feature, latlng) { return L.circleMarker(latlng, { radius: 8 }); }, onEachFeature: (feature, layer) { if (feature.properties feature.properties.name) { layer.bindPopup(feature.properties.name); } } }).addTo(map); }) .catch(err console.error(加载GeoJSON失败, err));这段代码做了三件事创建地图、加载底图、用fetch请求GeoJSON文件并渲染。关键点在fetch返回的JSON直接传给L.geoJSONLeaflet内部会解析每种几何类型并渲染到地图上。circleMarker是常用的点样式你可以根据需要换成L.circle、L.marker或者根据属性值动态设置颜色。如果项目用的是Vue或React这类框架思路完全一样只是把fetch和L.geoJSON的调用放进组件的生命周期函数里。只要保证数据格式是标准的FeatureCollection地图库就能正确识别。所以你在QGIS里把GeoJSON导得越规范前端代码就越简单这是一个前后端互相成就的事情。4.2 在线URL与跨域部署几个容易忽略的坑GeoJSON文件通常作为静态资源放在服务器上前端通过HTTP请求获取。这里有几个部署层面要注意的问题。第一个是跨域。如果你在本地直接双击HTML文件去fetch一个本地GeoJSON文件浏览器会直接报跨域错误。解决方式很简单本地开发用VS Code的Live Server插件起一个本地静态服务或者把GeoJSON内容直接写成一个JavaScript对象放进代码里线上部署时要确保服务器配置了正确的CORS响应头或者把GeoJSON部署在跟页面同源的路径下。第二个是路径统一。项目里如果还存在原有的MapServer或GeoServer服务GeoJSON文件可以和它们分开存放但前端代码里要统一配置成相对路径不要写死绝对路径否则换环境就挂。第三个是关于国内可用的在线底图资源配置。前面代码示例里用的OSM底图在部分网络环境下访问不稳定实际项目中建议优先使用组织内部发布的瓦片服务或者使用国内网络环境访问稳定的公开底图服务。底图服务地址和GeoJSON数据文件是两回事GeoJSON本身就是那份矢量数据不依赖外部网络但可视化的底图要保证能稳定访问才行。给前端提供GeoJSON文件时我一般会额外准备一个小工具页面一个简单的HTML页面中间放一个地图自动请求所有GeoJSON文件并标注每个文件的要素个数和大小。这样每次数据更新后拉到这个页面看一眼就能快速确认数据都正常。4.3 性能优化数据瘦身与压缩GeoJSON用起来方便但也有一个很明显的问题同样的矢量数据它比Shapefile大比GeoPackage更大。原因很简单JSON文本格式为了可读性大量使用括号、冒号、逗号、引号这些字符对程序来说是负担对体积来说也一样是负担。一个几万条记录的面图层GeoJSON轻松突破几十MB前端直接加载会被卡到怀疑人生。面对这种情况我有几招常用的处理方式。第一招是简化几何。在QGIS里用“处理”工具箱找到“简化”工具设定合适的容差比如0.0001度到0.001度大概是10米到100米级别在线段密集的区域抽稀节点可以在不明显损失视觉效果的情况下把几何数据量压缩到原来的三分之一甚至五分之一。第二招是裁剪属性。前面说到字段精简这一步再做一次确保只保留前端用得到的属性字段。前端弹窗只需要name那就在导出前把area、open_time这些字段删掉能省空间就省空间。第三招是文件压缩。GeoJSON是文本对gzip压缩极其友好。部署到Nginx等Web服务器时开启gzip压缩前端请求到的传输数据体积能再压掉60%到80%。这是收益最高、成本最低的优化手段强烈建议优先搞定。如果数据量实在太大比如几十万条要素那就不要再考虑单个GeoJSON文件了。把数据导入PostGIS通过GeoServer或MapLibre这样的服务发布矢量瓦片前端按需加载体验会好很多。GeoJSON在这种场景下只作为小体量数据、临时数据或离线数据的交付格式。5. 常见问题与排查实录踩坑速查表这部分是我最想写的。下面的问题几乎都是我真实踩过、或者帮同行排查过的按问题现象、原因、解决思路三列放在表格里方便你后续遇到问题时直接查阅。问题现象可能原因解决思路前端显示要素位置全部偏移到海外或坐标值极大源数据是投影坐标系导出GeoJSON时未设置目标CRS为4326在QGIS导出对话框里把CRS改为EPSG:4326重新导出点位的经纬度显示反了南北和东西颠倒坐标顺序写成了[纬度, 经度]按RFC 7946规范改成[经度, 纬度]或在QGIS中用字段计算处理属性里的中文全部显示为乱码文件编码不是UTF-8或读取时指定了错误的编码在QGIS重新添加图层时手动指定UTF-8或导出时选择UTF-8大文件在浏览器里加载卡死GeoJSON文件体积太大要素过多简化几何、精简属性字段、开启gzip压缩数据量大时改矢量瓦片方案在QGIS里保存GeoJSON时提示缺少唯一id字段QGIS需要主键字段才能保存要素编辑结果在属性表添加一个整型唯一序列字段后再编辑保存前端能加载底图但GeoJSON要素不显示数据坐标范围与底图投影范围不匹配或请求文件跨域失败检查F12控制台跨域报错确认坐标是经纬度临时文件用本地静态服务访问多边形渲染出来形状奇怪出现交叉或扭曲几何可能存在自相交或坐标顺序问题用QGIS“修复几何”算法处理或者检查坐标点是否重复、乱序从DWG转来的数据导出GeoJSON后位置完全不对CAD源坐标系与目标坐标系不一致先确认CAD原图坐标系在QGIS中正确指定后再导出转换5.1 坐标翻转一个隐藏很深的坑坐标翻转的问题我单独拎出来讲因为太容易踩了。GeoJSON标准规定坐标顺序是[经度, 纬度]但很多第三方工具、老版库甚至一些人手写的坐标串用的是[纬度, 经度]。如果前端渲染时拿到的是这种数据差异在低纬度地区可能很隐蔽但在中国区域经纬度一个在几十度范围一个在百度范围翻转之后点位会直接跑到完全无关的地方去。我排查过的一个真实案例是数据在QGIS里显示正常导出GeoJSON后用Leaflet加载点位置明显偏了但是偏移量看起来又是固定的不是完全乱掉。最后检查发现是当初某个处理环节用了Excel做字段拼接把经纬度两个字段反着拼了进去。所以如果你遇到“QGIS里正常前端偏了”的情况第一反应就应该是检查坐标顺序用一段小脚本批量验证几个已知位置的坐标值是否满足经纬度范围。5.2 中文乱码根源在编码中文乱码在GeoJSON里太常见了。问题根源就在于GeoJSON标准强制UTF-8但很多数据是从Excel、老式GIS软件、或者Windows记事本里导出来的文件实际编码可能是GBK或GB2312。QGIS加载时如果自动检测编码失败你在属性表里看到的就是一串串的“锟斤拷”。处理方式我在前面提过用“图层”→“添加矢量图层”重新添加文件在编码设置里手动指定UTF-8如果指定UTF-8后还是乱码通常说明源文件其实是GBK编码那就指定GBK或GB18030等数据在属性表里显示正常后再执行导出输出编码选UTF-8这样前端拿到的就是干干净净的中文了。5.3 数据太大卡死浏览器怎么判断该不该放弃单个GeoJSON如果一个GeoJSON文件超过10MB前端解析起来就有明显卡顿了超过50MB浏览器基本会处于“假死”状态。判断要不要继续用单个GeoJSON我的经验标准是这样的要素数量在几千以内、单文件压缩后小于5MB用GeoJSON完全没问题要素数量上万或者文件超过20MB建议用矢量瓦片或者把数据按区域切分成多个GeoJSON文件前端按需加载。QGIS里做一个简单的分区导出也很方便在属性表里按行政区字段选中一批要素右键“导出”→“要素另存为”就可以只导出选中部分。这样把一个全国层的数据拆成省或市级别的小文件前端逐级加载体验会好特别多。注意如果你要用gzip压缩GeoJSON记得测试压缩前后的加载时间。文本压缩率高但解压也需要时间实际优化效果要在目标网络环境下用DevTools实测别只看文件体积变小就以为万事大吉。5.4 几何无效看起来很正常的文件前端却渲染失败还有一种坑是几何有效性。地理数据在拓扑上必须满足一定约束比如多边形的外环必须是闭合的、环与环不能自相交、点坐标必须在有效范围内等等。很多数据在原始生产环节就存在这些问题QGIS浏览时因为容错机制看起来一切都正常但前端地图库对几何的解析往往更严格遇到无效几何就直接报错或者整层不渲染。解决这类问题QGIS里最方便的工具是“修复几何”。在“处理工具箱”里搜索“修复几何”对图层执行一次它会自动消除悬空节点、修复自相交、封闭未闭合的环然后重新导出GeoJSON。虽然修复后的几何会在一些极小的细节上有变化但绝大多数场景下不影响业务使用。需要注意的是修复工作最好在Shapefile阶段或者GeoJSON导出前完成不要让“脏几何”流到生产文件里。最后说点我的使用习惯做了这么些年GIS和Web开发我的经验是GeoJSON不是万能的但它是目前矢量数据交换场景下兼容性最好、学习成本最低、前后端协作最省心的格式。我的个人习惯是把GeoJSON当作“交付格式”而不是“工作格式”日常编辑管理用GeoPackage或PostGIS只有需要把数据给前端、给客户、或者做离线数据分析的时候才用QGIS导出成GeoJSON。小数据量直接整文件传输大数据量就走切分或者矢量瓦片方案。如果你现在正好卡在“QGIS导出的文件前端显示不出来”这个问题上我建议你先别急着改代码回头看一下导出GeoJSON时CRS选没选对编码是不是UTF-8。这两点解决了至少能避开我见过的一半以上翻车现场。后面等你把GeoJSON用顺手了还可以往前端动画渲染、服务端数据简化、瓦片发布这些方向继续扩展地理数据这条路越往深走越有意思。