做三维地图和可视化项目，绕不开“算距离”这个需求。早先做某物流调度演示项目时，我要计算两架无人机之间沿地表的真实航程，然后每隔一定距离取一个检查点。开始图省事，直接把两个经纬度转成三维坐标求直线长度，结果画出来的轨迹是一条穿入地心的直线，距离数字也明显不对。查文档才发现，Cesium里有个名字不怎么起眼但非常核心的工具类——EllipsoidGeodesic，它专门处理椭球面上的测地线计算，能一次解决三个问题：两点之间沿地表“走”的真实距离、起终点的大地方位角，以及在这条最短路径上按弧长或比例插值。这篇文章就从原理到实战把它拆透，适合WebGIS前端、Cesium使用者，以及任何需要在椭球地表做轨迹、测量、航向计算的场景。

1. EllipsoidGeodesic到底在解决什么问题

1.1 为什么要算“测地线”，而不是连一条直线

先明确一个很多人忽略的事实：Cesium里的地球模型不是球，而是旋转椭球，默认采用WGS84椭球参数。所谓测地线，是椭球面上两点之间最短的那条曲线路径，相当于你把地球表面沿着某条路径“展开”后，那条被拉伸成直线的线。在地图上看到A到B的航线是一条弧线，并不是飞机故意绕弯，而是因为地图投影把曲面压平了，曲面上的最短路径在平面图里自然呈现为曲线。

那为什么不能直接连直线？因为在三维场景中，两个Cartesian3坐标之间的直线会直接穿过地球内部。你画一条线从地表这边穿到地心再穿到那边，看起来是直的，但它完全不代表任何真实运动路径。无人机不会钻地，船舶不会下潜，车辆更不会走地心隧道。椭球面上的测地线，才是贴着地表走的最短路线，也是所有轨迹类业务应该采用的基准线。

1.2 为什么球面大圆公式不够用

很多教程告诉你，用球面大圆距离公式算两点距离就行。但地球是一个两极稍扁、赤道略鼓的椭球，赤道半径约6378137米，极半径约6356752米，两者相差约21公里。这个差别在短距离场景里不明显，一旦做跨省、跨海、跨洲的长距离计算，或者做高精度的航路规划、管线选线、无人机任务路线，用球面近似造成的误差可能从几十米累积到数公里，这在业务上是不能接受的。

Cesium的内部几何体、地形和坐标转换都建立在椭球模型上，所以“地表距离、地表路径”这类计算，就应该放到椭球面上做，而不是退回到球面近似。EllipsoidGeodesic就是为这个需求设计的：它把WGS84椭球参数吃进去，给出椭球面上的测地线解算结果，距离单位直接是米，方便对接后续业务流程。

1.3 这个类解决的三个核心问题

按实际使用频率，EllipsoidGeodesic的核心价值可以归纳成三条：

第一，地表距离。你给它两个Cartographic坐标，它直接返回沿椭球面的测地线长度，单位是米，不用你自己去积分或者套公式。第二，大地方位角。它给出起点处和终点处的朝向角，也就是测地线在这两个点上的切线方向与正北方向的夹角，这个数据在做航向指示、模型朝向、方向判断时非常有用。第三，测地线插值。你可以在已知这条最短路径的前提下，按比例或者按实际弧长取出任意中间点坐标，这正好覆盖了轨迹点生成、动画路径采样、沿线标记布设等需求。

这三个能力组合起来，其实就是一套“椭球面上的大地测量工具包”。理解这一点，再看它的API就不会迷糊了。

2. 核心API逐项拆解与使用细节

2.1 构造一次，拿到距离和双端方位角

EllipsoidGeodesic的构造非常直接，传入起点、终点和椭球体即可。需要注意的是，起点和终点必须是Cartographic类型，也就是用经度、纬度、高度表示的点，而不是Cartesian3。Cesium里经纬度统一使用弧度制，所以推荐用fromDegrees方法来做转换，避免手算弧度。

// 示例坐标，业务里替换成你的数据 const start = Cesium.Cartographic.fromDegrees(110.2, 30.8); const end = Cesium.Cartographic.fromDegrees(120.5, 25.6); const geo = new Cesium.EllipsoidGeodesic(start, end, Cesium.Ellipsoid.WGS84); // 测地线地表距离，单位：米 console.log('surfaceDistance:', geo.surfaceDistance); // 起始方位角，返回弧度，转成度更直观 console.log('起始方位角:', Cesium.Math.toDegrees(geo.startingHeading)); console.log('结束方位角:', Cesium.Math.toDegrees(geo.endingHeading));

构造完成之后，三个关键属性就已经可用。surfaceDistance是整条测地线的弧长，单位米。startingHeading是测地线在起点处切线与正北方向的夹角，向北为0度，顺时针增加，范围用弧度表示。endingHeading同理，是终点处的切线方向。

这里有个新手高频踩坑点：heading的单位是弧度。如果你把它直接当成角度传给模型旋转接口，模型会转得乱七八糟。要得到0到360度的角度，用Cesium.Math.toDegrees转换后，再按需取模归一化。

2.2 两条插值路线的差异和用法

EllipsoidGeodesic提供了两个插值方法，这是它区别于普通距离计算工具的核心优势。interpolateUsingFraction接收一个0到1之间的小数，比如0.5表示整条测地线的中点；interpolateUsingSurfaceDistance则接收以米为单位的弧长值，表示从起点沿着测地线走过多少距离后取点。

// 按比例取中点 const mid = geo.interpolateUsingFraction(0.5); console.log('中点经度弧度:', mid.longitude); console.log('中点纬度弧度:', mid.latitude); // 按实际距离取点：从起点沿测地线走100公里 const point = geo.interpolateUsingSurfaceDistance(100000);

两者的区别在于业务表达方式。如果你关心“整条路的中间位置在哪”，用fraction更直接。如果你关心“无人机飞行了80公里后应该到哪”，用surfaceDistance更贴合业务语义。无论哪种方式，返回结果都是Cartographic，经纬度依旧是弧度制，需要转成度数或者直接用fromRadians转成Cartesian3。

实际使用中有一个注意点：interpolateUsingSurfaceDistance的distance参数，建议限制在0到surfaceDistance之间。小于0或者超出总距离的结果虽然也能算出来，但业务上可能出现难以理解的坐标，最好在调用前夹取一下。

2.3 复用实例，避免重复解算

EllipsoidGeodesic的构造过程并不是简单的代入公式就结束，它内部涉及迭代解算，有一定计算量。如果在循环里或者每帧渲染里反复new实例，会造成不必要的开销。正确做法是创建一次实例，用setEndPoints方法改变起终点，重复使用。

const geo = new Cesium.EllipsoidGeodesic(); // 批量计算多条测地线距离 const routeList = [ [startA, endA], [startB, endB], [startC, endC] ]; routeList.forEach(([s, e]) => { geo.setEndPoints(s, e); console.log('当前距离:', geo.surfaceDistance); });

另外，插值方法的最后一个参数是result，可以传入一个预先创建好的Cartographic对象。这样避免了每次插值都生成新对象，在需要连续取几千个轨迹点的高频场景下，能明显减少垃圾回收压力。一个典型的优化写法就是循环外准备result，循环内反复调用。

3. 底层计算思路：椭球面上的最短路径是怎么解出来的

3.1 从“大地方位角”说起

要理解测地线，必须先理解方位角。地球表面每个点都有一个“当地北方向”，这个方向由椭球在该点的切线平面确定。当你站在起点面朝终点，你的视线方向与正北方向的夹角，就是大地方位角。测地线的关键特性是：它在每个点上都有一个瞬时方位角，这个角随着位置变化而变化，而不是像平面上直线那样始终保持同一个方向。

反算的思路是：已知起点和终点的经纬度，求初始方位角。你可以先把初始方位角猜成一个值，然后沿着这个方向在椭球面上“走”一段距离，看看最终落到哪里，再根据落点和目标点的偏差修正初始方位角，反复迭代直到收敛。这本质上就是一个数值求解过程。

3.2 数值迭代与归化纬度

Cesium内部并不是简单套一个现成公式，而是采用了经典的大地测量学思路。椭球面上的测地线方程可以借助“归化纬度”来简化，把旋转椭球问题转化为更易处理的参数形式。通过归化纬度，椭球面上复杂的曲率变化被映射到一组相对简洁的微分关系里，再结合数值积分逐步推进。

你可以把整个过程理解为：从起点出发，沿着某个初始方位角，把测地线分成许多微小段，每段都按照当前点的椭球曲率调整方向，走走停停地积分出一条曲线。如果终点偏差太大，就调整初始方位角再来一遍。这个过程类似二分法或者牛顿迭代，目标就是让积分曲线最终精确穿过目标点。

这也解释了为什么构造EllipsoidGeodesic实例会有一定开销：它不是在算一个线性公式，而是在做一次收敛计算。理解了这一点，你就能明白为什么2.3节建议复用实例，而不是每次测量都从零开始迭代。

3.3 为什么结果精度可以做到很高

因为整个过程基于WGS84椭球参数，并且通过迭代收敛到目标点，所以测地线距离和方位角的精度远高于平面近似和球面近似。在大多数工程场景下，误差控制在极小范围内，完全够用。

这里我也想提醒一句：精度高不代表你可以忽略椭球模型的选择。如果你在做一个非地球场景，比如火星或者月球表面的可视化，默认的WGS84椭球就不适用，需要构造对应的Ellipsoid实例传入构造函数。Cesium本身支持自定义椭球，但很多人没注意这个参数，导致计算的距离和实际场景对不上。

4. 该用它还是用别的：距离计算方案横向对比

4.1 四类常见写法的含义和误差

日常开发里，判断“两点距离”至少有四种写法，它们的结果可能差别很大，用途也完全不同。我把它们放在一起对比，方便你按场景选型：

重点是中间两行。很多新手以为把经纬度差求平方和开根号就是距离，这是错的。经纬度本身是角度单位，直接用平面欧氏公式得到的结果既不是米也不是英里，完全无法用于业务。Cartesian3.distance虽然单位是米，但它是三维空间里的直线长度，对于远程跨区域计算，两点连线会穿入地球内部，数值上比真实地表距离短不少。

4.2 场景化选型建议

如果你只需要一个距离数值，对方向和路径不关心，Ellipsoid.getSurfaceDistance是最轻量的选择，直接传两个Cartographic进去就能拿到以米为单位的距离。但如果后续还要生成航点、做轨迹动画、获取航向角，我建议直接上EllipsoidGeodesic，因为它的插值能力和方位角属性都是现成的，省得你从距离结果再反推。

这里补充一个很容易被忽略的点：EllipsoidGeodesic的插值结果是“椭球面上的点”，它和实际地形的起伏没有关系。如果业务需要沿着真实地表地形飞，你需要对每个插值点再做一次地形高度采样，把height字段填上，再生成最终坐标。这个步骤不能省，否则轨迹会悬浮在地形上方或者低于地形。

5. 实战案例：等距航点生成与贴地轨迹动画

5.1 每隔10公里生成一个航点

回到我开头说的物流调度场景。假设两架无人机要从起点飞到终点，需要在航线上每隔一段距离设置检查点，用于模拟中继通信或状态上报。如果用比例插值，航线不是等距的，不方便按业务规则触发。这时候interpolateUsingSurfaceDistance就派上了用场。

const start = Cesium.Cartographic.fromDegrees(110.2, 30.8); const end = Cesium.Cartographic.fromDegrees(120.5, 25.6); const geo = new Cesium.EllipsoidGeodesic(start, end, Cesium.Ellipsoid.WGS84); const totalDistance = geo.surfaceDistance; const step = 10000; // 每10公里一个点 const waypoints = []; for (let d = 0; d <= totalDistance; d += step) { const carto = geo.interpolateUsingSurfaceDistance(d); waypoints.push(carto); console.log('航点坐标（度）:', Cesium.Math.toDegrees(carto.longitude), Cesium.Math.toDegrees(carto.latitude)); }

这段代码的关键在于，从起点开始按固定弧长逐步向前推进，保证每个航点之间的地表距离都是10公里。你还可以把最后一个点单独补上，让终点也出现在航点列表里，避免因为整除问题漏掉终点。

5.2 沿测地线生成平滑运动轨迹

另一个常见需求是让实体沿着地表路径做平滑运动，比如无人机、飞机或者船只的轨迹动画。很多人的第一反应是用Cartesian3.lerp在两个坐标之间做线性插值。这个思路在本地小范围可能看不出来问题，一旦距离跨到几百公里以上，线性插值出来的中间点就会直接陷入地球内部，轨迹显示出来是一条穿地的直线，完全失真。

正确做法是用测地线插值生成一系列坐标点，再配合Cesium的SampledPositionProperty按时间采样，让实体沿着这些点运动。

const positionProperty = new Cesium.SampledPositionProperty(); const startTime = Cesium.JulianDate.now(); const totalSteps = 100; for (let i = 0; i <= totalSteps; i++) { const fraction = i / totalSteps; const carto = geo.interpolateUsingFraction(fraction); const position = Cesium.Cartesian3.fromRadians( carto.longitude, carto.latitude, carto.height ); const time = Cesium.JulianDate.addSeconds( startTime, i * 60, new Cesium.JulianDate() ); positionProperty.addSample(time, position); }

这样生成的轨迹每隔一段就落在测地线上，最后一个点和终点完全重合，运动速度也均匀。相比之下，笛卡尔线性插值得到的是一条空间直线，测地线插值得到的才是沿地表的弯曲路径，两者放到地图上一眼就能看出差别。

5.3 动态航向推演与模型朝向

除了轨迹，很多场景还要求实体朝向随路径变化，比如机头要始终朝着飞行方向。EllipsoidGeodesic只给出起点和终点的方位角，那运动过程中的朝向怎么算？

我的做法是取相邻两个插值点来推算。已知当前点和下一点的经纬度，可以用当前点的测地线方位角作为此刻的航向。实际操作中，更简单的方案是：在生成轨迹点的时候，额外记录每个点的插值参数，然后使用相邻两点构造一个临时EllipsoidGeodesic实例，取startingHeading作为当前朝向。

function getHeadingAt(cartoA, cartoB) { const temp = new Cesium.EllipsoidGeodesic(cartoA, cartoB); return temp.startingHeading; // 弧度，作为模型朝向 }

这个技巧的本质是利用局部的测地线方向来逼近该点切线方向。点间距越小，结果越接近真实瞬时方位角。不过要注意，这种方式在点非常密集时会频繁构造临时实例，建议在循环里复用同一个小工具对象，或者手动缓存相邻点的计算结果，避免性能抖动。

6. 常见问题与排查技巧实录

6.1 问题速查表

我在实际项目里遇到过的坑，以及身边同事踩过的坑，整理成一张表，方便你对照排查：

这些坑的高发区基本都集中在单位换算和模型选择这两个方面。只要把弧度、度、米、曲面路径这四件事理清楚，大半问题就解决了。

6.2 我在项目里踩过的几个坑

第一个坑是轨迹穿地。当时做某跨区域路径规划Demo，直接把起终点转成Cartesian3之后用线性插值生成点集，结果整个航线在地球内部穿行，离地表越来越远。后来我在中间取一个点转回Cartographic，才发现它的纬度明显不对，这才意识到线性插值路径不在地表上。换成EllipsoidGeodesic插值之后，路径立刻贴回地面，效果完全不一样。

第二个坑是弧度制和角度制混用。有一阵子我把一个经度值直接当度数传给一个需要弧度的内部函数，结果定位点跑到了完全错误的位置，排查了很久才发现是单位问题。所以我现在写代码有个习惯：所有从Cartographic出去的经纬度，要么立刻转成度数，要么在变量名前加radians后缀，绝不在同一个函数里混用两种单位。

第三个坑和性能有关。有一个页面需要同时展示几百条航线，每条航线上几百个点，最初我在循环里反复new EllipsoidGeodesic对象，浏览器直接卡顿。改成统一复用几个实例，配合setEndPoints切换起终点后，计算耗时大幅下降。这个优化对数据量大、更新频率高的场景非常明显。

6.3 实用调用姿势总结

根据经验，我整理了一套比较稳的调用模式。首先，统一用Cartographic.fromDegrees构造起终点，从源头避免弧度换算问题。其次，把EllipsoidGeodesic实例的生命周期尽量拉长，能复用就复用，不要每帧创建。第三，插值取点如果需要密集采样，提前准备好result对象传入插值方法，减少对象创建。第四，业务上需要显示成角度时，最后一步再统一用toDegrees转换，不要中间反复横跳。

另外，如果团队内有其他人维护代码，建议在调用处加一行注释，写明“此处返回经纬度为弧度，单位为米”，这类跨单位的数据最容易在交接时出问题。

我个人在项目里的体会是，EllipsoidGeodesic属于那种平时不起眼、用错了很要命的工具。下次你再遇到“两点距离对不上”“轨迹穿地”“航向不对”这类问题，先别怀疑数据源，回头看看是不是没用对椭球面上的测地线。最后再分享一个扩展思路：这个类虽然只提供椭球面上的计算结果，但结合地形高度采样，你可以生成真正贴合地表起伏的飞行轨迹，在这个基础上还能继续做视锥分析、坡度约束、航线可行性检查。这个方向我后面也在继续玩，等有更完整的经验再单独写一篇。