JavaScript GIS 库选型：Turf.js 与 JSTS 的功能对比

作者：闭包旅人

时间：2026-11-03

深度对比 JavaScript 空间计算库 Turf.js 与 JSTS 的功能差异、底层架构、精度模型、拓扑鲁棒性、性能表现与选型实践指南。

文章目录

一、核心定位与底层计算模型差异

任何空间计算库的算法行为与性能特征，都由其底层数据结构和空间数学假设决定。Turf.js 和 JSTS 在架构层面的出发点截然不同：

1. 数据载体与内存模型：Turf.js 将标准 RFC 7946 GeoJSON 作为一等公民。调用 Turf 函数时，输入是普通的 JavaScript 字面量对象（Feature、Polygon 等），输出也是标准的 GeoJSON。整个调用链没有多余的对象封装与中间解析层，与 Leaflet、Mapbox GL JS、OpenLayers 等现代地图框架无缝对接。相比之下，JSTS 源自经典的 JTS 面向对象几何模型，在进行空间计算前，必须通过 jsts.io.GeoJSONReader 或 WKTReader 将数据反序列化为内部的 jsts.geom.Geometry 拓扑对象，计算完毕后再通过 GeoJSONWriter 转出。这种面向对象的内部模型虽然带来了额外的序列化开销，但能够维护半边拓扑结构、拓扑节点树以及顶点序列。

2. 坐标空间与测地线计算：Turf.js 针对 Web 地图的高频痛点，原生内置了球面大地测量学（Geodesics）模型。例如计算两点间距离（turf.distance）、缓冲区（turf.buffer 默认输入公里/米单位）或多边形面积（turf.area）时，底层直接采用 Haversine 或 Vincenty 大圆航线算法处理 WGS84 经纬度（EPSG:4326）。而 JSTS 纯粹运行在二维笛卡尔平面坐标系（Cartesian）上，它将所有坐标视为无量纲的平直欧几里得平面点（X, Y）。若直接传入经纬度计算距离或缓冲区，JSTS 只能以“度”为单位进行简单的平面几何勾股定理计算，在高纬度地区会产生严重的形变失真。因此，在 JSTS 中开展具有工程实际物理尺寸（如 500 米缓冲区）的计算时，业务端必须自行负责前置坐标投影（如投影至当地 UTM 或 EPSG:3857），并在输出时执行逆投影。

JavaScript GIS 库选型：Turf.js 与 JSTS 的功能对比 — 图 1：Turf.js 与 JSTS 底层计算架构与数据处理管道对比

二、拓扑鲁棒性与精度模型对比

在地理信息系统中，“拓扑有效性（Topological Validity）”是空间布尔分析（相交、联合、差集）能否稳定运行的基石。根据 OGC Simple Features 规范，一个合法的多边形边界不得自相交，外环必须封闭且逆时针旋转，内环（洞）必须顺时针旋转且完全位于外环内部，且不得出现相切于一点的沙漏形（Bowtie）或悬挂线。

1. 浮点精度与自相交容错：在实际项目中，来自 CAD 导入、人工手绘或第三方公开接口的矢量数据常常包含未闭合、自交或微小裂隙等脏数据。Turf.js 的底层布尔运算主要依赖裁剪库（早期版本依赖 martinez-polygon-clipping，新版逐步演进为 polyclip-ts），基于标准 IEEE 754 双精度浮点计算。当输入的两个多边形边界存在近距离微小自相交或顶点微小抖动时，Turf.js 极易出现边界追踪死循环、洞丢失或直接抛出计算异常。更为重要的是，Turf.js 本身并不提供开箱即用的拓扑自检与自动修复函数。

2. JSTS 的工业级精度网格与拓扑修复：JSTS 全盘继承了 JTS 经过数十年地理工程验证的鲁棒性拓扑算法。

拓扑诊断：提供 geom.isValid() 验证几何合法性，并通过 jsts.operation.valid.IsValidOp 的 getValidationError() 精确输出非法原因（如 Self-intersection、Hole lies outside shell）以及发生冲突的具体坐标点。
经典修复手段 buffer(0)：对于包含自相交、自重叠或环向错乱的多边形，在 JSTS 中执行 geom.buffer(0) 或 jsts.operation.union.UnaryUnionOp，拓扑引擎会自动在线段交汇处插入交点节点（Noding），打散线段并重新构网，自动将其转化为合法的 MultiPolygon，这一操作在 GIS 行业被称为“拓扑自愈黄金法则”。
精度模型（PrecisionModel）：JSTS 支持设置固定精度网格（Snap-Rounding）。当两个多边形共享的边界由于浮点舍入存在 1e-8 米的微小间隙（Sliver）时，JSTS 会强制将相近顶点吸附到同一个网格格点，从根本上消除了连续布尔运算导致的坐标漂移与退化死角。

三、核心功能与算子覆盖度横向对照

为了清晰展现两款库在实际业务功能上的覆盖差异，下表汇总了 GIS 常见分析场景与算子支持情况：

功能大类	Turf.js 特性与算子	JSTS 特性与算子	场景推荐
基础布尔运算 (相交/联合/差集)	`turf.intersect`, `turf.union`, `turf.difference` 语法直观依赖外部裁剪库，复杂几何偶发拓扑报错	`geom.intersection()`, `geom.union()`, `geom.difference()` 严格鲁棒遵循 OGC 规范，支持精度网格约束	简单面用 Turf 工业级用 JSTS
海量要素级联联合 (Cascaded Union)	需循环调用 `turf.union`，随要素数量增长呈现 O(N²) 性能劣化与浮点误差叠加	`CascadedPolygonUnion` 基于空间索引构建 R-Tree 分治树合并，时间复杂度 O(N log N)，抗崩溃能力强	首选 JSTS
拓扑校验与修复	仅提供基础的 `turf.booleanValid`（且覆盖度有限），无内置的自愈构面算子	`IsValidOp` 详细诊断定位错误，`BufferOp.bufferOp(geom, 0)` 与 `UnaryUnionOp` 自动修复非简单面	首选 JSTS
打散构面与网络分析 (Polygonize & Noding)	不支持。仅支持基础的多边形外边框提取（`turf.polygonize` 在核心库已弃用或受限）	`Polygonizer`（由任意相交线网提取封闭多边形面）、`LineNoder`（线相交自动打断节点化）功能完备	首选 JSTS
空间关系谓词	`booleanPointInPolygon`, `booleanIntersects`, `booleanContains` 等封装函数	完整支持 DE-9IM（九交模型）矩阵判定：`relate(other, matrixPattern)`、`contains`、`covers` 等	通用交互用 Turf 严格学术/规整用 JSTS
测地学与物理尺寸	原生支持千米/米/英里单位，基于 WGS84 椭球体自动换算距离与缓冲区	纯平面无量纲计算。不支持物理单位换算，必须在外部自行投影并转单位	首选 Turf.js
高级空间分析与插值	内置丰富扩展：等值面（`isobands`）、等值线（`isolines`）、空间聚类（`clustersKmeans`）、贝塞尔曲线平滑	专注纯几何拓扑，不包含统计学、等值插值或可视化相关的高级空间分析算子	首选 Turf.js

四、开发体验与代码实现范式对比

在实际编写代码时，两者的 API 风格差异显著。以下通过两个典型场景的代码对照，直观展现它们的调用习惯与思维模式。

场景 1：多边形缓冲区分析与求交

假设需求：读取两个 GeoJSON 多边形，为第一个多边形生成 200 米的缓冲区，并求其与第二个多边形的相交重叠区域。

Turf.js 实现方式：

import * as turf from '@turf/turf';

// 输入标准 WGS84 GeoJSON 格式
const poly1 = { "type": "Feature", "geometry": { "type": "Polygon", "coordinates": [[[116.39, 39.90], [116.41, 39.90], [116.41, 39.92], [116.39, 39.90]]] }};
const poly2 = { "type": "Feature", "geometry": { "type": "Polygon", "coordinates": [[[116.40, 39.91], [116.42, 39.91], [116.42, 39.93], [116.40, 39.91]]] }};

// 1. 直接指定米制单位计算缓冲区（Turf 内部自动完成经纬度到米尺度的测地换算）
const buffered = turf.buffer(poly1, 0.2, { units: 'kilometers' });

// 2. 直接求交，输出即可直接传递给 Mapbox/Leaflet 渲染
const intersection = turf.intersect(turf.featureCollection([buffered, poly2]));
console.log(intersection.geometry);

JSTS 实现方式：

import jsts from 'jsts';
// 注意：poly1_projected 和 poly2_projected 必须先投影为平面米制坐标系（如 EPSG:3857 或 UTM）

const reader = new jsts.io.GeoJSONReader();
const writer = new jsts.io.GeoJSONWriter();

// 1. 反序列化为 JSTS 拓扑内部几何对象
const geom1 = reader.read(poly1_projected.geometry);
const geom2 = reader.read(poly2_projected.geometry);

// 2. 执行平面缓冲区计算（200 单位，基于输入坐标系的平面距离）
const bufferedGeom = geom1.buffer(200);

// 3. 执行严格拓扑求交
const intersectedGeom = bufferedGeom.intersection(geom2);

// 4. 重新序列化输出为 GeoJSON（随后需根据业务决定是否逆投影回 WGS84）
const resultGeoJSON = writer.write(intersectedGeom);

场景 2：数据质检、自交面修复与级联联合

在处理城市规划红线、土地利用图层等工业级数据时，往往包含数以百计相互重叠、边界复杂的面要素，且可能夹杂手绘导致的自交面。在此场景下，JSTS 展现出了不可替代的鲁棒性。

import jsts from 'jsts';

// 拓扑修复函数：检测并自愈非法多边形
function cleanAndRepairGeometry(jstsGeom) {
  const validator = new jsts.operation.valid.IsValidOp(jstsGeom);
  if (!validator.isValid()) {
    const err = validator.getValidationError();
    console.warn(`检测到非法几何: ${err.getMessage()} 坐标: ${err.getCoordinate()}`);
    
    // 利用 buffer(0) 强制打散节点并重构成合法面
    return jstsGeom.buffer(0);
  }
  return jstsGeom;
}

// 批量合并 1000 个复杂多边形（避免 Turf.js 循环 union 的 O(N^2) 性能暴跌）
function batchCascadedUnion(polygonGeomArray) {
  const cleanedList = polygonGeomArray.map(cleanAndRepairGeometry);
  
  // 使用 JTS 级联联合分治树，高效合并无拓扑崩溃
  const cascadedOp = new jsts.operation.union.CascadedPolygonUnion(cleanedList);
  return cascadedOp.union();
}

五、打包体积、执行性能与运行环境

在选择技术栈时，客户端工程往往对资源打包体积（Bundle Size）有极高的敏感度，而服务端数据处理则更注重计算吞吐量与算法复杂度。

1. 前端打包体积与按需引入：Turf.js 采用了彻底的现代前端模块化设计。在 npm 生态中，Turf 不仅提供了整体包 @turf/turf，其每个功能也独立发布为独立的子包（如 @turf/buffer、@turf/boolean-point-in-polygon）。如果项目仅仅需要点在面内的判断，开发者只需引入 @turf/boolean-point-in-polygon，Gzip 压缩后的体积仅约 3KB ~ 6KB，对首屏加载几乎无感。而 JSTS 由于高度移植自 JTS 的大型类继承体系（包含了完整的坐标链表、拓扑图结构、工厂类和算法套件），即使采用现代 ES Module 打包并开启 Tree-Shaking，其核心运行时仍然较为庞大（Gzip 后通常在 150KB ~ 250KB 以上）。因此在极端追求首屏速度的移动端或轻量 Web 应用中，直接引入 JSTS 存在一定的包体积压力。

2. 空间索引与计算吞吐量：对于单次轻量级几何操作（如判断光标所在经纬度是否落在某个行政区内），Turf.js 零对象开销的执行速度极快。但当场景切换到重度计算——例如上千个要素之间的多对多求交筛选、复杂面合并时，Turf.js 由于缺乏原生的高性能空间索引树，通常退化为双重循环遍历，时间复杂度快速恶化。而 JSTS 原生内置了工业级二维空间索引树（如 STRtree 空间紧密 R 树与 Quadtree 四叉树），能够在内存中快速完成两组海量几何对象的包围盒过滤（Filter Step），再对候选集做精确拓扑计算（Refinement Step），整体吞吐效率大幅超越基础循环。

运行环境选型建议：

浏览器主线程（轻交互 UI）：优先采用 Turf.js。体积微小、零序列化延迟，能直接与地图渲染器的数据源双向通信。
Web Worker / 后端 Node.js 服务：对于需在后台线程执行的大批量数据拓扑清理、CAD 构面、空间 ETL 任务，推荐使用 JSTS。配合 Web Worker 可避免 JSTS 的大计算量阻塞浏览器主线程渲染帧率。

六、选型决策路径与混合落地方案

为了帮助研发团队在技术选型时迅速定位最适方案，建议遵循以下决策流程逐层递进：

在明确了单一库的边界后，成熟的地理信息系统常常采用“前端交互轻量化，后端拓扑工业化”的混合协同架构：

用户交互侧（Turf.js）：在前端地图视图中，用户使用鼠标绘制多边形、动态拖拽顶点、测量两点间公里数、实时展示缓冲区阴影，全部使用 Turf.js 完成。响应时间处于毫秒级，且无需维护复杂的投影转换。
数据提交与入库侧（JSTS）：当用户点击“提交审批/保存成果”时，GeoJSON 数据传入后台 Node.js 微服务（或前端后台 Web Worker）。此时利用 JSTS 将经纬度数据投影至国家标准投影坐标系，调用 IsValidOp 进行重叠与自交审查；若发现自相交缺陷，触发 buffer(0) 自愈；随后与底图红线执行 difference 切割，确保入库矢量数据的绝对拓扑正确性。

七、工程落地避坑指南

结合实际工程项目中的常见问题，总结以下四条关键避坑准则：

1. 警惕在 JSTS 中直接传入 WGS84 经纬度做缓冲区：
新手常犯的错误是在 JSTS 中直接写 geom.buffer(100)，期望获得 100 米的缓冲带。但在 JSTS 中，如果输入的几何数据是经纬度，100 会被当作 100 度（相当于跨越了上万公里）。切记在使用 JSTS 做距离/缓冲区分析前，必须使用 proj4js 将坐标投影为以米为单位的平面坐标系（如 UTM 或 Web 墨卡托 EPSG:3857）。

2. Turf.js 循环 union 会出现雪崩式性能衰减：
避免使用 features.reduce((acc, cur) => turf.union(turf.featureCollection([acc, cur]))) 逐一合并数百个面。这种写法的计算量是阶乘递增的，且每次浮点求交都会使坐标精度产生微小畸变，最终导致第 N 次合并时抛出底层裁剪错误。要素量大于 50 时，应果断改用 JSTS 的 CascadedPolygonUnion。

3. 警惕 Web 墨卡托投影在高纬度带来的面积变形：
如果在 JSTS 中将数据投影至 EPSG:3857 计算面积或距离，越靠近两极区域，投影形变率越大（纬度 60 度处面积会夸大 4 倍）。如果要计算大范围跨纬度要素的精确物理面积，应使用 Turf.js 的 turf.area，或者在 JSTS 前置处理时采用等面积投影（如 Albers 等面积割圆锥投影）。

4. 避免在前端频繁进行 JSTS Reader/Writer 序列化：
GeoJSONReader 和 GeoJSONWriter 的开销与顶点数量成正比。如果一次交互包含数万个顶点，频繁在 GeoJSON 与 JSTS 内部拓扑对象之间往返会产生显著的垃圾回收（GC）停顿。若必须在前端进行密集计算，应尽量在内存中保留 JSTS 几何对象，全部计算完成后再执行一次性写回。