Cesium航线规划实战：插值、动态漫游与相机跟随全流程

简介：一套基于CesiumJS的无人机航线规划可运行源码，面向Web GIS开发者和无人机任务规划人员，实现了类似大疆司空2的航点设计、航段插值与三维动态渲染。压缩包内共3个文件，以index.html核心可视化页面、.inscode云端运行配置和.gitignore工程规范文件组成，整体仅8KB，轻量易部署。目前已有44人学习下载，适合正在解决航线箭头渲染难题、希望快速搭建三维航迹可视化原型的开发者参考。代码采用Canvas离屏生成箭头图案，再通过Cesium.Material绑定至PolylineGeometry，绕开了着色器与纹理贴图的复杂方案；同时支持WGS84经纬度输入、KML/SHP批量导入、鼠标拖拽航点实时重算航段、滚轮缩放自动重采样箭头密度等交互，内置撤销重做快捷键，并给出航点属性、航段模式、航线容器的分层设计，可作为浏览器端航线规划项目的起步模板或课程设计参考。

1. 项目概述：Cesium航线规划到底在解决什么问题

要说Cesium航线规划，得先搞清楚一个前提：Cesium（注：网上经常有人打成“Ceisum”，其实指的是同一个东西，CesiumJS）是一个基于WebGL的三维地球和地图开源JavaScript库。它的核心能力是把地球“塞进浏览器”，你不需要装任何插件，打开网页就能在三维地球上渲染地形、影像、模型，还能做飞行漫游、轨迹回放、态势推演这些事。

做WebGIS或者数字孪生类项目的朋友应该都有体会：在二维地图上画一条航线很简单，API直接拉一条线就行。但到了三维场景，事情就变了味儿。你得考虑航线怎么在地球曲面上贴合地形走、飞行器在拐弯的时候姿态怎么平滑变化、整个漫游过程怎么和Cesium的时间轴（Clock）同步、相机要不要跟随飞行器、如果用户拖动视角以后怎么恢复……这些问题一个处理不好，航线规划做出来就是“一帧一帧跳着飞”的PPT效果。

这篇文章要讲的，就是一套可运行的Cesium航线规划实现方案。我按自己做过的项目经验，把从数据准备、曲线插值、动态漫游到相机跟随的完整链路拆开讲一遍，每个环节给出实际的代码思路和参数取值，你照着搭一遍基本就能跑出效果。适合刚接触Cesium不久、想实现三维航线播报或飞行漫游的开发者，也适合已经在做相关功能、但觉得实现细节不够顺滑的朋友用来对照排查。

1.1 核心需求拆解

先别急着写代码，把需求理清楚。一条完整的Cesium航线规划功能，通常包含下面几个子需求：

• 在三维地球上以可视化方式展示航线的路径轨迹，通常是一条带箭头的线条或管状体。
• 支持多个航路点（Waypoint）之间的路径规划，航路点之间要平滑过渡，不能是直角硬拐。
• 支持动态漫游：飞行器（或其他移动对象）沿着航线运动，运动过程与Cesium的时钟系统同步，速度可控。
• 支持视角跟随：漫游过程中相机可以自动跟随飞行器，也可以切换为自由视角，让用户从不同角度观察。
• 性能要可控：航线长、航路点多的情况下动画不能卡成幻灯片。

这几点是标配。如果你的业务里只需要“静态展示一条线”，那直接看接下来的“轨迹创建”部分就够了；如果要做到“可运行的动态漫游”，那四个部分都得看。

2. 整体方案选型：为什么是“插值 + 时钟驱动”而不是“逐帧改坐标”

先讲一个我在初学阶段踩过的坑。最早我实现动态漫游，脑子里冒出来最直接的想法就是：开一个定时器（setInterval或者requestAnimationFrame），每过一小段时间把飞行器的位置往后移一段，然后更新实体的position。听起来顺理成章对吧？但实际跑起来问题一堆。

第一个问题是位置更新不平滑。定时器间隔稍微一抖动，运动速度就会不均匀，视觉上像在“一瘸一拐”地走。第二个问题是和Cesium自己的渲染机制冲突。Cesium内部有一套渲染时钟，你要是用另一个定时器去驱动位置，两边不同步，放大缩小地图的时候尤其明显。第三个问题是交互问题——一旦飞机飞出了屏幕，你得自己去算怎么把相机拉过去，自由度很低。

后来我翻Cesium的官方示例才发现，人家早就给了一套更合理的模式，核心就是两件事：构造一条随时间变化的位置曲线（property），然后把这条曲线交给Cesium实体系统去驱动。

Cesium里有一个底层概念叫Property（属性），简单说就是一个“随时间变化的值”。你给它一个时间点，它就能返回当时的值。位置用PositionProperty，朝向用VelocityOrientationProperty，视角跟随用的则是Viewer的clock和camera结合。

航线规划的完整技术链路是这几步：

1. 准备好航路点的经纬度和高度坐标。
2. 用这些坐标构造一条插值曲线，把离散的航路点变成一条连续路径。
3. 把“距离”和“时间”绑起来：计算整条航线的总长度，按设定速度算出总耗时，再算出每个采样点对应的时间戳。
4. 创建一个动态实体（比如一架飞机模型或一个圆柱体），把它的position绑定到这条时间-位置曲线上。
5. 让Cesium的Clock从起点时间开始跑，实体就自动沿着航线动了。
6. 设置相机跟随模式，让视角保持“盯着飞行器看”或“从后上方跟着飞”。

这套模式的优势在于：所有过程都由Cesium的时钟统一驱动，位置、朝向、相机、时间轴全部同步，而且你不用自己去写帧循环，代码量小很多，稳定性也高得多。后面我会逐个环节展开。

2.1 插值算法怎么选

航线平滑的本质是数学插值。给你一堆离散点，你要在这些点之间“猜”出一条连续曲线，而且这条曲线不能乱拐、不能飞出去跟地形打架。

Cesium里提供了几个常用方案：

• LinearApproximation：线性插值，就是点与点之间连直线。简单粗暴，但拐弯的时候是折角，适合地铁路线这种本来就不是连续飞行的场景。
• CatmullRomSpline：Catmull-Rom样条插值。这是最常用的方案，它保证曲线经过原始航路点，而且切线方向在航路点处是连续的，所以拐弯平滑，整体形态自然。
• HermiteSpline：Hermite样条。除了经过航路点，你还可以指定每个点上的切线方向，控制力更强，但需要多准备一套切线数据，业务上一般用不到。
• Quadratic/其他高阶拟合：一般不用，容易过拟合，出现奇怪的弯曲。

我的实际经验是：默认优先选Catmull-Rom，尤其在航路点本身已经人工编辑过、形态基本合理的情况下，Catmull-Rom的效果最自然。它有一点“过拟合”的倾向（比如在某几个点靠得太近时可能会穿地），但通过控制航路点分布距离基本可以规避。

有人会问，为什么不直接用Cesium官方示例里那种“按固定时间间隔匀速飞”的思路？因为那种方式只适合演示用，真实业务里航路点之间的距离往往不均匀（第一段500米、第二段5公里），如果按固定时间间隔跑，速度就不一样了。所以我们要做一步“按弧长分配时间”的处理，这一步是很多教程里忽略的，但恰恰是航线漫游顺不顺的关键。下一节详细讲。

3. 核心实现：从坐标到一条能“跑起来”的航线

先说数据准备。假设我们有这样一条飞行计划（经纬度/高度）：

A: [116.3913, 39.9075, 1000] // 北京某点，高度1000米 B: [116.5213, 39.9375, 1200] C: [116.6513, 39.8775, 1500] D: [116.7813, 40.0075, 1800] E: [116.9113, 39.9675, 2000]

这些坐标怎么来的？可以是用地图工具人工标点，也可以是后端航线规划算法算好以后通过接口下发。前端拿到这批坐标以后，第一步要做的不是画线，而是把经纬度坐标转成Cesium可用的笛卡尔坐标。

Cesium里表示三维空间位置最推荐的是Cartesian3（地心笛卡尔坐标）。经纬度转Cartesian3有两种方式：

// 方式一：直接用 Cesium.Cartesian3.fromDegrees const position = Cesium.Cartesian3.fromDegrees(lng, lat, height); // 方式二：先转弧度，再转笛卡尔，适合批量处理 const cartographic = Cesium.Cartographic.fromDegrees(lng, lat, height); const position2 = Cesium.Cartographic.toCartesian(cartographic, Cesium.Ellipsoid.WGS84);

两种方式效果一样。方式二适合你后续需要做坐标系换算的场景。性能上几十个点不会有感知差异。

3.1 构造插值曲线

拿到了坐标数组，接下来构造曲线。先说结论，我是这样做的：

const points = [ Cesium.Cartesian3.fromDegrees(116.3913, 39.9075, 1000), Cesium.Cartesian3.fromDegrees(116.5213, 39.9375, 1200), Cesium.Cartesian3.fromDegrees(116.6513, 39.8775, 1500), Cesium.Cartesian3.fromDegrees(116.7813, 40.0075, 1800), Cesium.Cartesian3.fromDegrees(116.9113, 39.9675, 2000) ]; const spline = new Cesium.CatmullRomSpline({ times: [0, 1, 2, 3, 4], points: points });

这里有一个非常关键的细节：times不能随便填。

在CatmullRomSpline里，times数组的长度必须和points一致，而且必须严格递增。很多教程直接写[0, 1, 2, 3]这种等差序列，但这是有问题的——它假设每个航路点之间的“时间消耗”是一样的，可实际上两个航路点之间的距离不一定一样。A到B可能只有1公里，B到C却有5公里。如果时间间隔一样，那飞行速度就忽快忽慢。

正确做法是：先计算每条航线段的距离，然后按距离占比分配时间间隔。我直接给你一个计算函数：

function computeDistance(p1, p2) { return Cesium.Cartesian3.distance(p1, p2); } function generateSplineTimes(points, speed) { // 计算每一段的长度 const segmentDistances = []; let totalDistance = 0; for (let i = 0; i < points.length - 1; i++) { const d = computeDistance(points[i], points[i + 1]); segmentDistances.push(d); totalDistance += d; } // 按距离比例分配时间累积 const times = [0]; let accumulated = 0; for (let i = 0; i < segmentDistances.length; i++) { accumulated += segmentDistances[i] / speed; times.push(accumulated); } return { times, totalDistance }; }

speed的单位要和Cartesian3.distance返回的单位保持一致。Cesium里Cartesian3.distance返回的是米，所以speed就是米/秒。一般无人机或直升机漫游，100米/秒是个合理的演示值，相当于360公里/小时。当然这个值完全看你的业务场景来定。

拿到times以后，再传给CatmullRomSpline，这样插值出来以后，样条曲线上任意一点都有对应的“时间坐标”，后续驱动飞行器的时候就自然了。

3.2 把曲线绑到实体上

接下来创建飞行实体。这里有两种做法，先看常规的、适合大部分场景的做法：用一个简单的圆锥体或圆柱体作为飞行器的替身，好处是渲染开销小、不需要加载模型文件。

const flightEntity = viewer.entities.add({ position: new Cesium.SampledPositionProperty(spline), point: { pixelSize: 10, color: Cesium.Color.RED }, orientation: new Cesium.VelocityOrientationProperty(spline), path: { width: 3, material: new Cesium.PolylineGlowMaterialProperty({ glowPower: 0.2, color: Cesium.Color.DODGERBLUE }), leadTime: 50, trailTime: 50, resolution: 1 } });

这里有几个关键细节要展开说明：

position为什么传一个SampledPositionProperty？

其实你可以直接把spline传进去，Cesium的PositionProperty本身就能接受样条曲线。但按我的经验，用SampledPositionProperty包一层更稳，因为SampledPositionProperty默认会做线性插值之外的“采样”优化，避免Cesium在渲染时频繁计算样条曲线，对性能有帮助。如果你的航路点很多（成百上千个），这一步的差异就会显现出来。

orientation为什么要用VelocityOrientationProperty？

这是最容易抄错的地方。如果不设置orientation，实体的朝向在三维空间里是乱七八糟的——它可能面朝北，也可能面朝上，取决于实体的默认朝向。VelocityOrientationProperty的作用是：根据当前位置的速度方向，自动计算出“头朝运动方向、上下方向指向地球法线方向”的姿态。这样飞行器看起来才像真的在“朝着航线方向飞”，而不是平移。

3.3 时间轴同步与相机跟随

实体创建完以后，航线只是“静态”的。要让飞行器动起来，还需要把Cesium Viewer的时钟拨到航线起点，让时钟开始走。

const start = Cesium.JulianDate.now(); const totalDuration = spline.times[spline.times.length - 1]; // 秒 const stop = Cesium.JulianDate.addSeconds(start, totalDuration, new Cesium.JulianDate()); viewer.clock.startTime = start.clone(); viewer.clock.stopTime = stop.clone(); viewer.clock.currentTime = start.clone(); viewer.clock.clockRange = Cesium.ClockRange.LOOP_STOP; // 到头后自动停止或循环，取决于业务需要 viewer.clock.shouldAnimate = true;

如果不想让用户手动拖动时间轴，也可以直接在代码里控制：

viewer.clock.shouldAnimate = true; // 让时钟自动走 viewer.clock.multiplier = 1.0; // 时间倍率，1.0就是1倍速

关于multiplier，这里有一个实操技巧。如果你调好了航线速度以后发现整个漫游太慢（比如航程几千公里，1倍速要飞一整天），不需要回过去改speed，直接把clock的multiplier调高就行。比如viewer.clock.multiplier = 60，相当于1秒动画里跑1分钟的距离。这个参数在演示场景里特别常用，建议做成一个UI滑块，方便实时调整。

相机跟随的实现，我用的是viewer.trackedEntity。这是最省力的方案：

viewer.trackedEntity = flightEntity;

只要设置好trackedEntity，Cesium会自动让相机跟随实体运动，并且根据实体的orientation调整相机的观察角度。不过trackedEntity的默认视角位置经常不是我们想要的——它有时候会跑得特别近，有时候离得太远。我一般会这样微调：

// 在trackedEntity之后手动设置视角俯仰角 viewer.scene.screenSpaceCameraController.enableTilt = true; viewer.camera.lookAtTransform(flightEntity.position.getValue(viewer.clock.currentTime)); viewer.camera.zoomIn(500); // 根据模型大小调整距离

但注意，如果你后续想加“自由视角”切换，直接取消trackedEntity就行：

viewer.trackedEntity = undefined;

切回来的时候重新赋值即可。这是个很自然的交互模式，我建议在UI上做两个按钮：“跟随视角”和“自由视角”，默认开跟随。

3.4 航线的可视化：静态线 + 动态尾部轨迹

飞行器本体有了，但光有飞行器还不够，观感上还是太空。至少要把整条航线在三维地球上画出来。这里我用两个实体，一个画静态预览线，一个画动态尾迹。

静态预览线很简单：

const linePositions = []; for (let i = 0; i <= 200; i++) { const t = (i / 200) * spline.times[spline.times.length - 1]; linePositions.push(spline.evaluate(t)); } viewer.entities.add({ polyline: { positions: linePositions, width: 4, material: new Cesium.PolylineDashMaterialProperty({ color: Cesium.Color.CYAN, dashLength: 16 }), clampToGround: false } });

这里为什么手动采样200个点而不是直接用spline本身？因为Cesium的Polyline不接受样条对象，它只接受Cartesian3数组，所以必须预先采样。采样的密度取决于航线复杂度，200个点对于几个航路点的航线已经足够平滑，如果航路点很多（比如环飞航线几百个点），建议把采样数提高到500甚至1000。

动态尾迹则是在飞行实体上通过Path属性实现的。刚才代码里已经出现过了：

// path里两个参数 leadTime 和 trailTime 表示尾迹向前和向后延伸的时间（秒） path: { leadTime: 30, trailTime: 100 }

tailTime大一点，尾迹就拖得长；leadTime小一点，前面的“虚线预览”就不至于挡视线。这两个值可以直接调，我建议初始值按照漫游总时长的1/10到1/5去取，效果比较理想。

4. 实操过程：完整可运行的实现步骤

前面讲了一堆原理，这一节把完整可运行的实现步骤串起来。我假设你已经有基础环境：Node.js已安装，新建了一个Cesium项目（具体用Vite或Webpack都行，不影响核心逻辑），并且已经在页面里初始化了一个viewer。

4.1 最小可运行代码

给你一段最小可运行的代码（基于Cesium 1.10x版本），先跑通动态漫游：

<!DOCTYPE html> <html lang="zh-CN"> <head> <meta charset="UTF-8"> <title>Cesium航线规划</title> <style> html, body, #cesiumContainer { width: 100%; height: 100%; margin: 0; padding: 0; } </style> </head> <body> <div id="cesiumContainer"></div> <script type="module"> import * as Cesium from 'cesium'; // 1. 初始化Viewer const viewer = new Cesium.Viewer('cesiumContainer', { terrainProvider: await Cesium.createWorldTerrainAsync(), animation: true, timeline: true, baseLayerPicker: true, geocoder: false }); // 2. 准备航路点 const points = [ Cesium.Cartesian3.fromDegrees(116.3913, 39.9075, 1000), Cesium.Cartesian3.fromDegrees(116.5213, 39.9375, 1200), Cesium.Cartesian3.fromDegrees(116.6513, 39.8775, 1500), Cesium.Cartesian3.fromDegrees(116.7813, 40.0075, 1800), Cesium.Cartesian3.fromDegrees(116.9113, 39.9675, 2000) ]; // 3. 按距离分配时间 const speed = 150; // 米/秒 const { times } = generateSplineTimes(points, speed); // 4. 构造CatmullRom样条 const spline = new Cesium.CatmullRomSpline({ times: times, points: points }); // 5. 创建飞行实体 const flightEntity = viewer.entities.add({ position: spline, orientation: new Cesium.VelocityOrientationProperty(spline), cylinder: { length: 80, topRadius: 10, bottomRadius: 10, material: Cesium.Color.RED }, path: { leadTime: 20, trailTime: 40, width: 5, material: new Cesium.PolylineGlowMaterialProperty({ glowPower: 0.3, color: Cesium.Color.GOLD }) } }); // 6. 调整相机跟随 viewer.trackedEntity = flightEntity; // 7. 设置时钟范围 const start = Cesium.JulianDate.now(); const stop = Cesium.JulianDate.addSeconds(start, times[times.length - 1], new Cesium.JulianDate()); viewer.clock.startTime = start.clone(); viewer.clock.currentTime = start.clone(); viewer.clock.stopTime = stop.clone(); viewer.clock.clockRange = Cesium.ClockRange.LOOP_STOP; viewer.clock.shouldAnimate = true; // 8. 静态航迹线 const staticPositions = []; for (let i = 0; i <= 200; i++) { const t = (i / 200) * times[times.length - 1]; staticPositions.push(spline.evaluate(t)); } viewer.entities.add({ polyline: { positions: staticPositions, width: 3, material: new Cesium.PolylineDashMaterialProperty({ color: Cesium.Color.CYAN, dashLength: 16 }) } }); // 9. 生成样条时间的工具函数 function generateSplineTimes(points, speed) { const segmentDistances = []; let totalDistance = 0; for (let i = 0; i < points.length - 1; i++) { const d = Cesium.Cartesian3.distance(points[i], points[i+1]); segmentDistances.push(d); totalDistance += d; } const timesArr = [0]; let accumulated = 0; for (let i = 0; i < segmentDistances.length; i++) { accumulated += segmentDistances[i] / speed; timesArr.push(accumulated); } return { times: timesArr, totalDistance }; } // 让地球先飞到航线上方 viewer.camera.flyTo({ destination: Cesium.Cartesian3.fromDegrees( 116.62, 39.94, 15000 ), orientation: { heading: 0, pitch: Cesium.Math.toRadians(-60), roll: 0 }, duration: 2 }); </script> </body> </html>

这段代码跑起来，你应该能看到：一个红色圆柱体从起点飞到终点，拖着一道金色尾迹，虚线勾勒出整条航线，相机自动跟随。

4.2 升级：换成真实的3D模型

如果业务需要让飞行器看起来更真实，最简单的做法是把cylinder替换成一个glTF或GLB模型，Cesium对这两种格式原生支持。你可以用Cesium官方示例里的战斗机模型（CesiumJS中自带的SampleData/models/CesiumAir/Cesium_Air.glb），也可以加载自己的模型。

创建方式改为：

const flightEntity = viewer.entities.add({ position: spline, orientation: new Cesium.VelocityOrientationProperty(spline), model: { uri: '/models/Cesium_Air.glb', minimumPixelSize: 128, // 保证远距离时不会太小看不见 maximumScale: 200 } });

注意这里有个坑：如果模型自带的坐标轴方向和实际运动方向不一致，你会看到飞机“横着飞”甚至“倒着飞”。velocityOrientationProperty默认假设模型的前方是模型的Z轴正方向，但很多glTF模型的前方可能是X轴正方向。这时候需要改模型的朝向，做法是给model属性加一个orientation偏移，或者用ModelInstance来调整。

一个简单的解决思路是：先把模型的本地坐标系在建模软件里统一成“Z轴朝前”（或者相反，取决于你的坐标习惯），这是最省事的方案。如果模型不能改，还可以在创建实体后手动加一个旋转适配，不过这块比较细，建议一般项目直接统一模型标准。

4.3 航线编辑与动态加载

实际的业务系统里，航线一般不可能是写死在前端代码里的，而是由用户在地图上绘制，或者由后端下发的。

用户绘制航线：给viewer加一个鼠标点击事件，每次点击记录一个坐标，双击结束绘制，然后调用上面的逻辑生成航线。

const handler = new Cesium.ScreenSpaceEventHandler(viewer.scene.canvas); const pickedPositions = []; handler.setInputAction((movement) => { const cartesian = viewer.camera.pickEllipsoid(movement.position, viewer.scene.globe.ellipsoid); if (cartesian) { pickedPositions.push(cartesian); // 画一个临时点 viewer.entities.add({ position: cartesian, point: { pixelSize: 8, color: Cesium.Color.WHITE } }); } }, Cesium.ScreenSpaceEventType.LEFT_CLICK);

这里用pickEllipsoid可以把屏幕坐标转成地球上的笛卡尔坐标。注意：如果地形开了，直接pickEllipsoid匹配的是椭球面而不是地形表面，你需要改用它拾取地形高度。

const scene = viewer.scene; const ray = viewer.camera.getPickRay(movement.position); const cartesian = scene.globe.pick(ray, scene);

后端下发航线：后端返回JSON数组，前端解析成Cartesian3数组，再走之前的标准流程。这种情况下我建议后端直接返回经纬度+高度的数组，前端做转换；不要在后端就转成Cartesian3，因为坐标系相关的东西最好集中在前端处理，避免两端坐标系定义不一致。

4.4 转向平滑：为什么用样条而不用“圆角”

细心的读者可能注意到一个重要问题：Catmull-Rom样条是从所有航路点上“穿过去”的，但真实飞行器的航线规划（比如无人机航测）通常是直线段+转弯弧的组合——因为飞机的飞控系统要求转弯时有个最小转弯半径。如果要模拟这种真实的航线，光用一条Catmull-Rom样条可能不够。

一个行业里常见的妥协方案是：在每段直线之间用圆弧过渡，圆弧半径根据最小转弯半径设定。这个方案我做过一版，核心逻辑是：把原航路点拆成“进弯点”和“出弯点”，用ArcCurve或自己算圆弧的圆心和半径。

不过说句实话，如果只是做可视化演示（不是给飞控用的实际航线规划），Catmull-Rom样条已经能提供很好的视觉平滑度了，没有必要引入圆弧拟合的复杂度。它的轻微“切削拐角”效果反而看起来挺像真实转弯。真正的航线规划算法（比如考虑禁飞区、地形避障、转弯半径约束）属于计算几何和优化算法的范畴，和Cesium前端可视化的关系不大，通常是后端在做。前端拿到后端给的航路点之后，用样条做视觉插值就够了。

所以我的建议是：可视化层用样条，业务层用直线段+转弯约束，两层分开。不要让前端可视化逻辑绑架了业务算法。

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

做Cesium航线规划的过程中，我整理了几个高频问题，几乎每个项目都会碰到。一个个说。

5.1 飞行实体朝向不对

现象：飞行器“横着走”或者“倒着走”，姿态怪异。

原因：VelocityOrientationProperty根据速度方向计算朝向，但它的计算结果默认基于对象本地的Z轴（或Y轴，取决于Entity是否设置了自定义轴）与速度方向对齐。不同的glTF模型坐标轴定义不一样。

排查：先用默认模型（比如一个小圆柱体）测试，如果圆柱体运动正常但导入的模型不正常，那问题一定出在模型的轴向上，想办法在建模工具里统一轴，或者在Entity的model属性里做旋转适配。

解决：给model属性绑一个固定旋转偏移，最粗暴但有效的做法：

model: { uri: '/models/MyAircraft.glb', // 注意：model没有直接的orientation属性，需要调整的是entity本身的orientation }

更推荐的办法是：创建实体时，用CallbackProperty包装一个自定义朝向，把VelocityOrientationProperty的结果再旋转一个固定角度。

5.2 航线穿地形

现象：航线从山体中间穿过，视觉上非常尴尬。

原因：航路点高度设置不合理，或者插值后曲线在某个区域低于地形高程。

排查：先关掉地形看航线是否正常；如果正常，说明航线本身OK，是地形的问题。

解决：有两个思路。一个是把航路点的高度提高，让所有航线都高于该区域最大地形高程。另一个是用terrain的sampleHeight方法，在采样航线的每个点时检测海拔，低于地形就把该点抬高到地形之上。后者更精细，但开销大一些，适合航路点比较少的情况。做飞行漫游演示的话，我觉得直接把高度拉高最省心，毕竟用户一般不会拿放大镜去检查航线是否贴近实际地形。

5.3 漫游过程中相机“穿地”或视角乱跳

现象：相机跟随飞行器的时候，偶尔会穿到地下去，或者视角瞬间跳一下。

原因：飞行器的航迹经过地形高处时，相机为了保持在飞行器后方/上方，和地形的相对位置产生了冲突。

排查：看看是不是飞行器飞到了地形拐角处。一般穿地都发生在山脊线上。

解决：方案一，加密航线采样，让曲线更平滑；方案二，手动把飞行高度整体上调。方案三（最实在的），设置相机的碰撞检测：

viewer.scene.screenSpaceCameraController.enableCollisionDetection = true;

这个开关默认就是true，但如果你在前置代码里关掉了（比如为了自由视角触控），记得恢复。

5.4 性能问题：航路点太多，动画卡顿

现象：航路点上万个，每次采样曲线时卡顿明显。

原因：CatmullRomSpline要维护一个很大的样条属性，加上实时采样时算法复杂度较高。

排查：先看是不是每次渲染都在重复计算。Cesium内部有自己的缓存，但如果你在代码里频繁调用spline.evaluate()，开销还是很大。

解决：最优解是提前把整条曲线采样到固定数量（比如1000个点），然后用SampledPositionProperty来驱动，而不是直接用样条。你可以把采样后的点传给SampledPositionProperty，并指定采样时间间隔，让Cesium在渲染时只做线性插值，而不是每次递归计算样条。

const sampled = new Cesium.SampledPositionProperty(); for (let i = 0; i <= 1000; i++) { const t = (i / 1000) * spline.times[spline.times.length - 1]; const time = Cesium.JulianDate.addSeconds(start, t, new Cesium.JulianDate()); sampled.addSample(time, spline.evaluate(t)); }

实测下来，这个方案能把大量航路点的帧率从个位数拉回60帧。

5.5 航线不显示

现象：代码逻辑看着没问题，但画面上就是不显示航线。

排查：列出常见的三个检查点：

1. 是不是Polyline的positions太少了？至少需要两个点。
2. 是不是所有点高度都为0，被地形遮住了？把clampToGround设成true，或者把高度设到100以上再试。
3. 是不是材质配置写错了？比如PolylineGlowMaterialProperty需要glowPower大于0，否则线条可能透明不可见。

还有一个很隐蔽的问题：当Viewer的requestRenderMode为true时，如果场景没有变化，Cesium不会重新渲染，线条可能“看起来没显示”。如果开了requestRenderMode，记得在添加实体后调用viewer.scene.requestRender()。

5.6 时间轴和动画不同步

现象：拖时间轴到某个时刻，飞行器并没有出现在预期位置。

原因：通常是因为你用的时钟startTime和Spline的times基准对不上。Spline的times是从0开始的相对时间，而Cesium的JulianDate是绝对时间。如果两者没有正确映射，时间轴上的任意一个时刻计算出的插值位置就是错的。

解决：统一基准时间。让Spline的times从0开始，然后在给SampledPositionProperty添加采样点时，把相对时间转换为start + t的绝对时间。这在前面的示例代码里已经体现，但很多人会忘掉这一步，所以特别提一下。

6. 一些没写在文档里的细节和心得

最后分享几个我实际项目中攒下来的经验，这些在官方文档里很难找到直接答案，但在做Cesium航线规划时非常有用。

第一个经验：控制器的坐标系转换。

Cesium的坐标系有三个层级：世界坐标系（ECEF地心坐标系）、场景坐标系（局部东北天坐标系）、屏幕坐标系。在做航线规划时，你大概率会频繁遇到坐标系转换问题。我建议项目中封装一组工具函数，专门处理经度纬度高度、Cartesian3、Cartographic之间的互转，防止业务代码里到处散落着一堆Cesium.Cartesian3.fromDegrees，后续维护的时候很容易找不着北。

第二个经验：动态目标的轨迹回放，建议用时间轴控件而不是自己做播放器。

Cesium的Timeline（时间轴控件）本身就是为这类场景设计的，你只要把时钟范围设好，用户就能自己拖动看航线。不要觉得自带的UI难看就禁用，其实配合Animation控件（播放/暂停/倍率按钮），体验比自己做的好得多。至少我做的项目里，客户对Cesium自带时间轴的接受度一直很高，我们只需要加几个自定义扩展按钮（比如加速回放、跳到起点）就可以了。

第三个经验：如果飞行的对象很多（几十上百个编队），不要用Entity，用CustomDataSource（或直接走Primitive，或者用Entity的批量创建+避开逐个update）。

Entity开发体验好，但性能上限低。编队演示或者多目标态势展示时，几十个Entity还撑得住，上百个就开始掉帧了。对那种场景，建议把几何体合并成Primitive，用一条大规模顶点缓冲区来做。不过这是进阶话题了，正常航线规划场景用不到。

第四个经验：版本问题。

Cesium的API近些年一直在演进。我写文章用的API版本比较新，如果你用的是老版本（比如1.9x），可能会遇到createWorldTerrainAsync这类新API不存在的情况，需要替换为createWorldTerrain。遇到报错先看版本号，这是排查Cesium问题最重要的第一步。

第五个经验：做好“兜底”UI。

航线规划作为一个功能模块，一定会和地图交互、数据管理、权限控制这些周边系统扯上关系。我每次做这类功能都会在最外层加一个状态机：空闲、添加航点中、航线生成中、漫游播放中、暂停。状态机的好处是防止用户在航线生成过程中误点地图，也方便你在状态切换时统一清理临时实体。这个习惯帮我少踩了不少脏坑。

这篇内容基本把Cesium航线规划从0到1的关键环节都过了一遍：方案选型、插值算法、时间轴同步、相机跟随、性能优化和常见问题排查。代码都是可以直接拿去改的，基于我自己的实践，跑通一个最小演示版应该用不了多少时间。后面如果你想继续深入，可以在这些方向上扩展：增加航路点拖拽编辑、接入后端航线算法、支持多飞行器编队、把航迹数据和业务系统打通。每个方向又可以写一篇文章了，我们下个主题再见。

本文还有配套的精品资源，点击获取