GeoLint：用ESLint规则引擎校验GeoJSON数据质量-编程实验室

如果你正在做前端地图可视化、数据治理或者给业务部门维护底图数据，应该能体会 GeoJSON 文件里那些“看起来没毛病、一上线就出问题”的坑：坐标数组少了一对括号、Feature 里漏掉 geometry、properties 字段名不统一、投影坐标没有声明。这类错误在浏览器里往往不会直接抛异常，而是变成地图白屏、图层偏移或者样式错乱，最后查半天才发现是数据源的问题。GeoLint 就是你在这个场景下的一个辅助工具：一个面向 GeoJSON 的 ESLint 风格校验器（linter），用规则化、可配置的方式把地理数据里的结构性问题提前挡在开发和发布流程之外。

很多人已经把 ESLint 当作前端工程的标配，但地理数据这一侧的自动检查一直比较原始。GeoJSON 本身是具备空间语义的 JSON，结构上和前端对象很相似，但真正用起来，它比普通 JSON 多了一整套坐标、几何类型、投影和拓扑规范。GeoLint 的思路就是把 ESLint 的“规则可配置、错误可定位、结果可自动化”这套机制，原样搬到 GeoJSON 上。这篇文章会从 GeoJSON 数据格式的设计讲起，分析数据文件为什么会出错、GeoLint 解决了哪些问题，再带你走一遍环境准备、命令行启动、规则配置、批量校验和 CI 接入的完整流程，最后给出针对性和可落地的排查清单与最佳实践。

1. 核心能力速览

先看一个概览，方便你快速判断这个工具适不适合进入你现有的技术栈和数据处理流程：

能力项	说明
项目类型	面向 GeoJSON 数据的命令行静态校验工具（linter），整体设计参考 ESLint 的规则机制
解决的问题	GeoJSON 文件结构错误、几何类型异常、属性字段缺失或命名不一致、坐标精度与范围异常等
使用方式	命令行（CLI），可以在终端中直接运行，也可以接入脚本、构建流程和 CI/CD
配置方式	配置文件声明规则，支持开启、关闭或调整规则级别，适合团队统一规范
批量任务	支持通过通配符或目录遍历多个 GeoJSON 文件，适合数据目录和前端素材目录批量检查
与编辑器关系	可直接处理原生 .geojson / .json 文件，也可以配合 VS Code、geojson.io、QGIS 等工具使用
硬件要求	无需 GPU，普通开发机即可运行，主要依赖 CPU 和内存
平台支持	依赖 Node.js 环境，通常跨平台可用，具体以项目 README 说明为准
是否提供修复能力	取决于项目是否内置 fix 子命令或自动修复规则，常见 lint 工具会提供相关扩展，需按实际文档确认
适合场景	前端地图开发、数据治理、底图发布前置检查、团队数据规范落地、地理数据类开源项目维护

从表格里能看出，GeoLint 的工具定位很明确：不替代 QGIS 这样的地理信息处理和可视化工具，也不替代 geojson.io 这类在线预览站点，而是作为“自动检查”的那一层，负责在数据进入渲染管线之前发现明显和不明显的结构问题。

2. 适用场景与使用边界

2.1 适合谁

第一类用户是前端工程师，尤其是做地图可视化、WebGIS、数据大屏的开发同学。这类场景里 GeoJSON 文件通常来源于第三方数据平台、后端接口或设计同事导出的底图，文件到手后如果手动打开，很难一眼看出坐标范围超出中国范围还是属性字段缺失。GeoLint 能把这些检查写成固定规则，集成到 npm scripts 里，每次拿到数据先跑一遍命令，再交给渲染层。

第二类是数据工程师和数据分析师。他们经常要下载和转换各种地理数据源，可能从省份边界、城市轮廓、路网、POI 数据等不同来源收集 GeoJSON 文件。这类数据往往格式来源混杂，字段命名风格不统一，几何类型忽而是 Polygon 忽而是 MultiPolygon。GeoLint 适合做“入库前校验”和“字段规范统一”的第一道关卡。

第三类是开源项目维护者、数据包维护者和团队技术负责人。当一个数据仓库或前端物料库包含几十上百个 GeoJSON 文件时，人工 Review 已经不可靠。配置一套标准规则后，在 Git 提交或 CI 阶段自动运行，能显著降低脏数据合入主分支的概率。

2.2 能解决什么问题

结构完整性：检查文件是否是合法的 GeoJSON，Feature、FeatureCollection、GeometryCollection 等顶层类型是否符合规范。
几何坐标合法性：坐标数组中经度、纬度的数值范围是否符合真实地理坐标（例如经度 -180 到 180，纬度 -90 到 90），坐标层级嵌套关系是否匹配几何类型。
属性字段一致性：校验 properties 中固定字段是否存在、字段类型是否一致、编码是否有问题。
投影坐标系声明：如果数据来自第三方来源，坐标是否统一到 WGS84（EPSG:4326），或者是否在数据说明中明确标出投影。
文件级规范统一：比如是否允许单个 Feature 文件、是否要求统一使用 FeatureCollection、文件后缀名和文件名规范等。

2.3 不适合什么场景

GeoLint 不负责帮你完成几何拓扑运算，比如检查坐标点是否落在某个多边形内部、线要素是否自相交、多个面之间是否存在缝隙，这些属于空间分析工具和拓扑校验工具的专业范围。它也不做地理数据格式转换，GeoJSON 转 TopoJSON、转 Shapefile、转 MBTiles 等需求需要搭配其他工具链处理。另外，GeoLint 解决的是“数据结构对不对”的问题，不解决“数据内容准不准”的问题——一个合法坐标并不能保证这个坐标代表的边界是正确的。

2.4 数据合规与使用边界

使用 GeoJSON 数据时，尤其是从网上下载的政区边界、道路路网、POI 数据，需要注意数据版权和授权范围。边界位置可能涉及测绘成果，部分数据来源有严格的发布限制，商用场景下要确认许可条款。中国境内地理数据的采集、处理和发布还必须符合测绘地理信息相关法规，涉及涉密信息的素材不能通过普通工具链处理和传播。这篇文章只讨论技术校验方法，实际使用中请务必确认数据来源合法、授权明确、发布内容不涉及敏感信息。

3. GeoJSON 数据格式与 GeoLint 的关系

搜索“geojson 数据格式”“geojson 用什么软件打开”这类问题的读者，通常正处在“手上有文件但不知道怎么检查”的阶段。GeoJSON 本质上是一个基于 JSON 的开放标准格式，用于表达地理要素及其属性。最简单的 GeoJSON 文件，是一个包含type和coordinates字段的几何对象；完整的地理数据文件则通常是一个FeatureCollection，下面包含多个Feature，每个 Feature 里有geometry和properties。

一个典型的 GeoJSON 对象大致是这个样子：

{ "type": "FeatureCollection", "features": [ { "type": "Feature", "properties": { "name": "示例区域", "code": "10001" }, "geometry": { "type": "Polygon", "coordinates": [ [ [116.0, 40.0], [117.0, 40.0], [117.0, 41.0], [116.0, 41.0], [116.0, 40.0] ] ] } } ] }

从数据结构看，GeoJSON 很规整，但恰恰因为“看起来只是普通 JSON”，很多人会忽略它的空间语义，直接把数组当成普通嵌套数组来拼。前端常见的错误包括：Polygon 的坐标数组层次少一层、环没有闭合、经纬度顺序写反、properties字段缺失、坐标数组里有空元素等。这类错误不会导致 JSON 解析失败，所以直接用JSON.parse很难发现，只有在渲染地图时才暴露出来。

GeoLint 的切入点就在这里。它和 ESLint 解决的问题本质上是同一类问题：ESLint 检查 JavaScript 代码的语法和风格问题，GeoLint 检查 GeoJSON 数据的结构和规范问题。两者都遵循“规则驱动”思路：规则是可插拔、可配置、可单独关闭的，规则执行结果会指出文件路径、行列位置、规则名称和错误描述，方便开发者在命令行里快速定位。理解了这层对应关系，你就不难推测 GeoLint 的基础使用路径：安装工具、准备配置、运行命令、查看报告，在拿到具体错误之后再回到源文件修改。

关于“geojson 用什么软件打开”这个问题，值得多说一句。GeoJSON 是纯文本格式，VS Code、Sublime Text 等编辑器都能直接当 JSON 打开；需要看图形效果时可以用 geojson.io 在线拖拽预览，或用 QGIS、kepler.gl 这类地理数据工具加载。GeoLint 的定位不是替代这些工具，而是在它们之前先做一次机械化检查，形成“编辑器打开 + 可视化预览 + 命令行自动校验”的组合工作流。

4. 环境准备与前置条件

作为命令行工具，GeoLint 的部署成本比数据可视化平台低得多，硬件门槛也很低。只要有一台普通的开发电脑，不需要独立显卡，不需要额外部署服务，也不需要准备大量磁盘空间。重点要检查的是软件环境。

4.1 基础环境检查清单

操作系统：Windows、macOS、Linux 都可以作为主环境，具体支持范围以项目 README 为准。
Node.js 环境：GeoLint 如果是基于 Node.js 开发的 npm 包，就需要本地有 Node.js 和 npm；建议先在本机执行node -v和npm -v确认版本。
终端工具：Windows 下建议使用 PowerShell 或 Windows Terminal，macOS/Linux 使用系统自带终端。
文件准备：准备一个待校验的 .geojson 或 .json 文件，可以先准备一个故意写错的测试文件。
编辑器：可选，VS Code 打开 JSON 文件查看结构比较方便。

4.2 确认 Node.js 环境

node -v npm -v

如果系统还没有 Node.js，可以前往 Node.js 官网下载 LTS 版本。这里不需要特定大版本，只要你本机的 Node.js 能顺利运行 npm 包即可。安装完成后，重新打开终端，再次执行上面的命令，看到版本号输出就说明环境正常。

4.3 准备测试文件

建议按下面的目录结构准备一个最小测试项目，方便验证：

geo-project/ ├── data/ │ ├── city.geojson │ └── region.geojson └── .geolintrc.json

data目录放待检查的 GeoJSON 文件，项目根目录放配置文件。第一次测试时，可以故意把一个 Polygon 的坐标层次改错，或者删掉properties字段，这样能更直观地看到 lint 工具的输出效果。

5. 安装部署与启动方式

5.1 通过 npm 安装

GeoLint 的正常安装路径是使用 Node.js 的包管理器。如果项目尚未初始化，可以先执行：

npm init -y

然后在项目内安装。以常见的 npm 包处理方式为例，安装命令大概是：

npm install --save-dev geolint

如果想全局使用，也可以尝试：

npm install -g geolint

注意，这里的geolint包名是参照常见的 linter 工具写法进行的示意，实际安装时请以项目 README 中给出的准确包名为准。安装完成后，可以通过执行不带参数的命令来确认工具是否就绪，例如：

npx geolint --help

如果能输出帮助信息、可用参数和配置文件查找逻辑，说明安装成功。

5.2 命令行启动

lint 类工具的基本工作方式是一致：输入一个或多个文件路径，工具读取配置，核心引擎按规则逐一执行，最后输出报告。GeoLint 的基础命令用法可以参照这个模板：

npx geolint ./data/*.geojson --config .geolintrc.json

这个命令表示：检查data目录下所有.geojson文件，使用根目录的.geolintrc.json作为规则配置。实际项目中，你需要根据 GeoLint 支持的参数替换--config和其他选项，比如是否输出 JSON 格式结果、是否只显示error级别、是否进入自动修复模式。如果你已经在项目里安装了本地依赖，并且不希望npx去远端查找，也可以直接写geolint。

5.3 通过 npm scripts 启动

日常开发中，把 linter 命令写入 package.json 脚本更便于团队复用：

{ "scripts": { "lint:geo": "geolint ./data/**/*.geojson", "check:geo": "geolint ./data" } }

这样执行npm run lint:geo就能跑一遍数据校验，也方便接进pre-commit、pre-push等流程。

5.4 其他启动方式

部分命令行工具会提供 Docker 镜像，方便在隔离环境中执行，避免污染开发机 Node 环境。如果 GeoLint 项目提供了官方 Docker 镜像，你可以参照镜像仓库的说明运行容器。以通用格式为例：

docker run --rm -v $(pwd)/data:/data geolint-image /data/*.geojson

这里的镜像名需要替换成项目实际发布名，$(pwd)/data是本地数据目录挂载到容器内/data的路径。Docker 方式更适合在 CI 里使用，本地开发阶段建议直接用 npm 方式，省去容器本身占用的额外时间和资源。

6. 规则配置与校验逻辑

GeoLint 和 ESLint 的相似之处，不只是名字，更重要的是配置和规则设计哲学。ESLint 允许插件通过rules对象配置每条规则的打开状态，GeoLint 很可能也遵循同样的思路。如果你拿到项目后文档里写了具体规则名，以文档为准；下面给出的是从 ESLint 经验推导出的通用示例配置，方便你快速理解这种工具应该怎么把规则落到项目里。

6.1 一个配置示例

{ "rules": { "no-invalid-geometry-type": "error", "no-missing-coordinates": "error", "no-empty-feature-collection": "error", "require-properties": { "level": "error", "options": { "requiredFields": ["name", "code"] } }, "coordinate-range": { "level": "error", "options": { "longitude": [-180, 180], "latitude": [-90, 90] } }, "feature-collection-only": "warn", "no-duplicate-feature": "warn" } }

这里的规则名和参数都是示意性的，为的是说明三类常用配置：

简单开关型规则，比如error或warn。
带自定义参数的规则，比如require-properties指定必须存在的属性字段。
带数值边界的规则，比如coordinate-range指定经纬度范围。

配置文件的格式大概率会支持 JSON，也可能同时支持 JS、YAML。如果你的项目同时存在多个数据目录，还可能有overrides或按目录覆盖配置的机制，类似 ESLint 对不同目录应用不同规则。

6.2 规则级别与输出行为

linter 的规则级别通常分三级。off表示关闭规则，不参与校验；warn表示校验到问题时只给警告，不改变进程退出码；error表示校验到问题时在输出中报错，并且在存在至少一个 error 的情况下让进程返回非零退出码。这个机制非常重要，因为 CI 里能否拦截提交，本质上依赖退出码。调试阶段建议先开warn，看报告再逐步调整；正式接入团队流程后，把必须守住的规则开成error。

6.3 自定义规则

如果你团队有内部数据规范，比如所有政区边界数据的properties里必须包含adcode和level，默认规则很可能覆盖不到。ESLint 社区的做法是写自定义规则插件，GeoLint 如果具备扩展接口，理论上也支持类似能力。建议你阅读项目文档中与“自定义规则”“插件”“访问器”相关的内容，看是否支持往配置对象里注入额外的验证函数。写自定义规则时要注意：输出信息要包含文件路径和明确的问题描述，避免把错误判定逻辑写得过于宽松或过于严格。

7. 功能测试与校验效果验证

工具安装完成、配置准备好之后，重点就是实际跑一遍。下面是按“最小验证 -> 多文件验证 -> 修复验证 -> 配置调整”四个阶段展开的测试流程。

7.1 最小验证：故意写坏一个文件

测试目的：确认 GeoLint 能正确解析文件、执行规则并输出错误位置。

操作步骤：

在 data 目录创建bad.geojson文件。
写入一个缺少coordinates或坐标层次错误的 Feature。
执行校验命令。
观察输出结果。

预期结果：命令行输出中会出现错误描述、规则名和发生错误的数据位置；如果写入了致命错误，进程退出码应为非零。

判断成功标准：你能在输出里定位到具体文件和问题类型，而不是只得到一个抽象的解析异常。

7.2 多文件批量校验

测试目的：验证 GeoLint 能否正确处理一个目录下的多个 GeoJSON 文件。

操作步骤：

npx geolint ./data/

如果项目支持 glob 通配符，也可以试试：

npx geolint "./data/**/*.geojson"

预期结果：工具按顺序遍历所有文件，逐个输出每个文件的校验报告，而不是遇到第一个坏文件就终止。

判断成功标准：报告中能看到每个文件名的独立分组，并且能统计出文件总数和错误总数。

7.3 自动修复验证

如果 GeoLint 提供了--fix或类似子命令，可以验证自动修复能力。自动修复通常只处理确定性、无歧义的错误，比如删除多余的分号、补齐空数组，这对应到 GeoJSON 可能就是补齐括号、统一缩进或移除空 Feature。测试时先备份原始文件，运行修复命令后，再运行一次不带--fix的检查命令，看错误数量是否下降。如果修复没有生效，说明对应规则不支持自动修复，需要手动改文件。

7.4 配置调整验证

测试目的：验证配置文件的优先级和覆盖行为。

操作步骤：在项目根目录先创建一个只包含“空 FeatureCollection”警告的配置，再在子目录创建一份把它改为error的配置，然后分别运行命令。

预期结果：子目录下的 GeoJSON 文件按更严格的配置执行，根目录文件按宽松配置执行。如果项目不支持多配置覆盖，这个测试会出现相同结果，这时需要考虑把数据按目录拆成多个 npm script 分头执行。

7.5 验证阶段容易踩的坑

配置文件没被读取：检查文件名和所在目录是否匹配工具约定。
规则名写错：配置里写一个不存在的规则名，工具可能直接报配置错误，也可能静默忽略，这取决于实现。
文件路径里有中文或空格：命令行执行时注意加引号。
多个文件里第一个就报错导致后面没继续跑：观察工具是“单文件失败即终止”还是“全部文件跑完再汇总”。

8. 批量任务与工作流集成

对于前端项目来说，GeoJSON 文件的规模通常不会特别大，因此 GeoLint 的批量任务，更多是指“一次命令跑完整个数据目录”和“在自动流程里无人工介入地执行”。

8.1 目录级批量检查

建议按数据类型组织目录结构，例如：

src/ assets/ geo/ boundary/ road/ poi/

然后配置三个 npm script，分别检查三个子目录。这样当数据局部变化时，可以只跑对应子目录，节省时间。如果数据量很大，检查脚本可以配合globby、fast-glob这类文件遍历工具，先过滤出变更过的文件列表，再逐个执行 GeoLint。更稳妥的做法是先用单个文件测试新的规则和配置，再把数据目录加进批量任务。

8.2 接入 Git hooks

如果你使用 Husky 管理 Git hooks，可以在pre-commit阶段运行：

npx geolint ./src/assets/geo

提交前发现数据问题会直接阻塞提交，适合对数据准确性要求较高的项目。如果不想严格阻塞，也可以先用warn级别观察一段时间。

8.3 接入 CI/CD

在 GitHub Actions、GitLab CI 或 Jenkins 中，GeoGeoJSON 校验可以放在构建之前的独立 Job 里。以 GitHub Actions 为例，可以写一个类似下面的步骤（文件名和包名需要替换为实际值）：

name: geojson-lint on: [push, pull_request] jobs: lint: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - uses: actions/setup-node@v4 with: node-version: 20 - run: npm install - run: npm run lint:geo

这样每一次代码推送都会自动检查 GeoJSON 数据文件。对于团队成员素质不一、经常不小心提交错误数据的项目，这一步能明显减少“测试环境正常、部署后地图空白”的问题。

8.4 批处理中的失败重试与日志

当文件数量很多时，建议把命令输出重定向到日志文件，方便后续排查：

npx geolint ./data > lint-result.log 2>&1

也可以让脚本在失败时输出 JSON 报告，再写一个简单脚本解析失败文件清单。如果 GeoLint 支持退出码区分“有警告”“有错误”“无问题”，那么在批处理脚本里可以针对不同退出码做不同动作。

9. 资源占用与性能观察

GeoLint 是命令行工具，不涉及 GPU 和显存，资源占用主要集中在 CPU 和内存上，运行窗口很短。它更适合和 ESLint 做类比：解析一个普通规模的 GeoJSON 文件，性能瓶颈通常不在单个文件的大小，而在文件数量和规则复杂度。

观察方法：

执行time npx geolint ./data，查看命令总耗时。
在任务管理器（Windows）或top（Linux/macOS）里观察 Node.js 进程的内存占用，确认没有内存持续上涨的异常。
用一个超大 GeoJSON 文件（几十 MB 或上百 MB）测试，看是否能正常完成校验、是否出现内存溢出。

如果你发现校验速度慢，可以从三个方向排查：文件是否过大、规则是否写得太复杂、是否每次启动都重新加载整个项目依赖。对于超大文件，linter 并不是最优手段，更专业的做法是用 OGR/GDAL 等空间数据处理工具做并行化的数据质量检查。日常开发场景下，GeoJSON 文件通常都在几 MB 以内，GeoLint 的启动时间和执行时间完全可以接受。

值得注意的一个点是：不要把 GeoLint 放进热更新或浏览器运行时。它是开发期工具，不是运行时工具。前端打包时不应该把 linter 的规则逻辑打进生产 bundle。

10. 常见问题与排查方法

问题现象	可能原因	排查方式	解决方案
运行`geolint`提示 command not found	全局安装失败或当前项目依赖未安装	执行`npm list geolint`，查看包是否在依赖列表里	重新`npm install`，或改用`npx geolint`
配置文件没生效，规则都没有执行	配置文件路径错误或文件格式不支持	检查命令中`--config`路径，确认配置文件扩展名	把配置移动到项目约定的默认名，或改用支持的格式
检查时报 JSON 解析错误	文件本身不是合法的 JSON，或文件里有 BOM 头、多余逗号	用 VS Code 打开文件，查看 JSON 语法是否标红	先修复 JSON 语法，再跑 GeoLint
坐标范围没有报错，但数据明显不对	没有启用坐标范围规则，或经纬度顺序写反但数值恰好在范围内	查看当前配置里是否包含范围规则；对比源数据标记的经纬度顺序	在配置中开启坐标范围规则，并明确坐标顺序约定
中文属性值乱码或显示异常	文件编码不是 UTF-8，或 Windows 下终端编码不一致	用文本编辑器查看文件编码	将文件转为 UTF-8 无 BOM 格式
命令行报`Permission denied`	全局安装目录权限不足	检查 npm 全局目录权限	使用本地依赖方式安装，避免用 sudo 强行安装
CLI 输出太啰嗦，看不清楚哪些是错误	没有设置输出格式或级别过滤	查看帮助文档，确认是否支持`--quiet`、`--format`	只显示`error`级别，或输出到文件再查看
CI 里跑不过，但本地没有问题	CI 环境 Node 版本不一致或依赖未装全	查看 CI 日志，确认 Node 版本和安装步骤	在 CI 中固定 Node 版本，先`npm ci`再运行校验
`--fix`执行后错误数量没有变化	对应错误不支持自动修复，或修复规则未开启	看报告里是否标注“可修复”标记	手动修改文件，或把修复规则单独配置

排查的总原则很简单：先确认“文件本身是否合法 JSON”，再确认“规则是否被正确读到”，最后看“退出码是否符合预期”。绝大部分问题都出在这三层的某一层上。

11. 最佳实践与使用建议

11.1 从最小规则集开始

不要第一次就把所有规则全部开成error。GeoJSON 数据太复杂，不同来源的数据规范差异很大，第一次全开大概率会让团队产生抵触情绪。建议先启用 4 到 6 条最能兜底错误的规则，比如合法几何类型、坐标存在性、FeatureCollection 结构、坐标范围，等跑通后再按团队规范加码。

11.2 保留一份“最小可运行配置”

把 GeoLint 配置、示例 GeoJSON 文件、安装命令写进项目 README。新成员拿到项目后，不用看完整文档，先跑一遍示例就能理解这个工具做了什么。这也方便你在未来升级或换工具时快速恢复流水线。

11.3 数据、配置、报告分目录管理

建议按下面的结构维护数据工程目录：

geo-project/ ├── data/ # 原始 GeoJSON 数据 ├── config/ # GeoLint 配置 ├── reports/ # 校验报告 └── scripts/ # 批量处理脚本

reports目录建议加入.gitignore，因为校验报告是过程产物，不应该频繁提交进仓库；但可以在 CI 里作为 Artifact 保留一份，便于追溯当前主分支的数据质量。

11.4 批量任务必须加日志和退出码判断

写脚本的时候不要只执行一条裸命令，至少要把退出码打印出来，把日志保留到文件。这样即使某天任务卡住或失败，你也能从日志里看到是哪一批数据、哪一条规则出问题。

11.5 数据授权和合规提醒

无论在你的项目里使用 GeoLint 校验多少遍，都无法替代对数据来源合法性的判断。下载公开 GeoJSON 文件时，注意查看数据提供方的许可协议；发布或商用前，确认数据是否包含受限制的测绘信息；涉及个人位置数据时，必须遵守隐私保护相关法律，不能因为数据格式上合法就忽略使用场景是否合法。

12. 总结与下一步

GeoLint 最值得尝试的点，是把 ESLint 那套成熟的规则引擎思路带进了 GeoJSON 数据质量检查，让原本靠肉眼和经验判断的地理数据问题，变成了可以自动执行、自动读报告、自动阻塞流程的工程化能力。建议你先准备一个破坏过的 GeoJSON 文件，安装工具后跑一遍最小校验，验证它能不能准确定位到你故意埋下的错误，再去阅读项目文档里的规则列表，按团队数据规范自定义配置。

最容易踩的坑是“配置了但没生效”和“规则开太猛导致噪音太多”，前者多查路径和文件名字，后者从最小规则集起步。如果 GeoLint 项目本身还在早期阶段，你可以重点观察它的规则扩展方式是否灵活、输出格式是否符合 CI 需求，再用几套真实数据样本做压测。

后续可以扩展的方向包括：把 GeoLint 接入 ESLint 生态做成 frontend 工具体系的一环、为上线的地图素材增加数据版本校验、结合自动化测试在每次构建后自动生成数据质量报告。对于手头有成百上千个 GeoJSON 文件的项目，先在数据侧建立标准，再谈可视化效果，是性价比很高的做法。建议收藏备用。