简介：Cesium飞行漫游是基于WebGL开源库Cesium构建的三维地球交互项目，面向前端GIS开发者与三维可视化学习者，解决在真实地形场景中实现相机平滑飞行、路线设定与交互浏览的问题。资源共6854个文件，压缩包58.26MB，包含3129个JavaScript逻辑文件、808个HTML页面结构、923个PNG图片及383个JPG纹理，同时配有CSS、JSON、GLSL着色器以及b3dm、gltf、pnts等三维瓦片与模型数据，目录完整、格式丰富。目前已有5849人学习浏览，适合用来研究Cesium的Viewer与Camera控制机制。通过内置的飞行漫游实现，可参考flyTo调用、飞行暂停与前后移动、路线点保存和加载、清空路线及退出飞行等完整交互流程，尤其适合希望快速搭建三维漫游原型或深入理解相机动画原理的开发者，入手后可直接运行调试，并根据项目结构扩展自己的功能。
1. 飞行漫游不是飞起来就完事：Cesium 里相机动画才是核心
很多人做 Cesium 飞行漫游，以为就是viewer.clock一跑、相机跟着路径点走一遍就完事。实际做出来要么镜头穿地、要么转弯时画面甩得像坐过山车、要么用户手动拖一下地图漫游状态就乱了。Cesium 飞行漫游的本质不是“模型在飞”，而是“相机在飞”——路径插值、朝向计算、时钟控制、地形避让这几件事必须协同好，才能出来一条丝滑的巡检航线。这篇文章我会把飞行漫游从路径设计到相机控制再到踩坑排查，按一套可复现的流程拆给你。适合刚接触 Cesium 的开发者，也适合做过但没深究过飞行参数的熟手，照着做就能在项目里落地一段不穿地、不眩晕、可控可停的飞行巡检动画。
2. 让相机先动起来：viewer.camera.flyTo 的局限与 lookAt 的正确用法
2.1 flyTo 能做漫游吗？能，但只是一锤子买卖
Cesium 里最常见的飞行函数是camera.flyTo。它接收一个目的地和相机姿态，然后内部自动做插值和缓动，两三秒把人从 A 点带到 B 点。这个函数用于“快速定位到某个位置”非常合适，比如用户点击列表里的一栋楼，视野飞过去看一眼。但如果你的目标是“沿着一条路径持续漫游，途经十几个点并且停下来看每个点的细节”，flyTo 根本不够用。
首先，flyTo 的destination和orientation是最终状态，中间过程完全交给 Cesium 内置的缓动算法。你没法在中间某个时刻插入“降低飞行速度观察左侧建筑”这样的动作。其次，flyTo 每次调用都会打断上一次飞行，连续调用多个点的 flyTo 时，动画是“跳变”的，不是衔接的——上一个点还没看稳，下一个点的动画就强制接管了。
我做模拟项目X的厂区巡检时试过用一个循环依次调用 flyTo 到各个巡检点，结果画面的表现是每隔 3 秒突然转头换个方向，没有任何连续感。所以要说清楚：flyTo 是“跳点飞行”，不是“漫游飞行”。漫游飞行需要的是你手动控制相机每一帧的位置和朝向。
2.2 lookAt 才是漫游的基础单元
和 flyTo 不同，camera.lookAt是“把相机放到一个相对于目标点的偏移位置，并朝向该目标点”。它的核心参数是一个HeadingPitchRange对象：
viewer.camera.lookAt( Cesium.Cartesian3.fromDegrees(116.391, 39.907, 50), new Cesium.HeadingPitchRange( Cesium.Math.toRadians(0), // heading：相机朝向，0 为正北 Cesium.Math.toRadians(-30), // pitch：俯仰角，负值表示从上方往下看 200 // range：相机与目标点的距离，单位米 ) )逻辑说明：lookAt的意思不是把相机“移”到目标点上，而是以目标点为球心，在你的HeadingPitchRange所定义的球面位置上放置相机，并始终看向球心。所以它天然适合漫游中的一个“观察点”——比如巡检路线上的某个设备、某段大坝坝面、某块边坡。
参数说明：heading 是绕 Z 轴的方向角，0 度指正北，90 度正东；pitch 是俯仰角，正值表示抬头仰视，负值表示俯视，-90 度就是垂直往下拍；range 是相机到观察点的距离，单位米。这三个值合起来决定了一个“固定的观察姿势”。
但注意，lookAt一旦设置，相机就被“锁定”了，用户用鼠标拖拽会发现视角转不动。所以在漫游结束后或某个观察动作完成后，要调viewer.camera.lookAtTransform(Cesium.Matrix4.IDENTITY)把相机的变换矩阵重置掉，否则后续交互会莫名其妙失灵。
2.3 用 Camera.setView 做瞬间定位：漫游前的底座
在写真正的路径漫游之前，还有一个基础动作要掌握：camera.setView。它用于瞬间把相机摆到一个指定位置，不做任何过渡动画。漫游路径的起点、中途的检查点、以及中途暂停后恢复漫游的位置，都需要先用它来“断电重启式”摆正相机：
viewer.camera.setView({ destination: Cesium.Cartesian3.fromDegrees(116.391, 39.907, 300), orientation: { heading: Cesium.Math.toRadians(0), pitch: Cesium.Math.toRadians(-45), roll: 0 } })逻辑说明：setView的orientation里的 heading 是相机朝向的角度，pitch 是俯仰，roll 默认保持 0。它比 flyTo 更快、更可控，多用于“瞬间切换到一个观察位置”的场景。漫游路径的第一帧通常用 setView 来定位，而不是 flyTo，因为 flyTo 的缓动会从“上一个位置”飞到起点，如果你的上一个位置在十万八千里外，这一下飞行动画会非常突兀。
参数说明：这里的destination是相机所在的世界坐标，不是观察目标的坐标。你可以理解为“相机站在哪”，而 orientation 是“镜头对着哪”。如果你把 destination 设到地下，相机会因为地形遮挡看到一片黑，这在实际项目里经常遇到——路径点设计时就必须保证所有相机的 destination 高于地表，不只高一点点，要考虑到地形起伏。
3. 路径设计：采样点、插值算法与地形贴合
3.1 路径点的来源：手写经纬度还是路线采集
飞行漫游的路径点通常有三种来源。第一种是手工指定——你在 Cesium 的 3D 场景里点选一系列位置，记录下经纬度和高度，然后写成一个数组。第二种是从 GeoJSON 或 Shapefile 里读取一条已有的线，比如一条道路中线、一条输电线路走廊。第三种是从模型的包围盒或关键设施点位自动生成巡检点。
我一般会建议混合用：先从业务数据里拿到兴趣点（设备、杆塔、坝段），然后用“偏离中线 + 固定镜头朝向”的方式生成每个兴趣点对应的相机位置。举个例子，一段大坝巡检，坝轴线是一串坐标，你希望相机从坝前 50 米上空飞过，斜视坝面。那你需要在每个坝段中心点的经纬度基础上，沿垂直于坝轴线的方向偏移 50 米，高度抬升 80 米，pitch 朝下看。
手写路径点最忌讳的是“点与点之间距离太大”。如果两个采样点相隔几公里，插值出来的路径可能直穿山体或建筑物。所以设计路径的关键不是“点要多”，而是“点密 + 高度合理”。在转弯较多、地形起伏剧烈的区域，采样距离应控制在 50~100 米，平地直行路段可以放到 300~500 米。
3.2 Catmull-Rom 插值：为什么不是线性插值
有了路径点之后，要生成一个平滑的飞行轨迹。你用线性插值在两点之间做匀速直线运动会看到明显的折角，转弯时画面突然甩一下。Cesium 自带的CatmullRomSpline这个插值类就是干这个的。它保证曲线通过所有控制点，同时在每个点处的一阶导数连续，也就是说“速度不会突变”。
const positions = [ Cesium.Cartesian3.fromDegrees(116.391, 39.907, 200), Cesium.Cartesian3.fromDegrees(116.393, 39.908, 220), Cesium.Cartesian3.fromDegrees(116.396, 39.909, 260), Cesium.Cartesian3.fromDegrees(116.398, 39.907, 240) ] const spline = new Cesium.CatmullRomSpline({ times: [0, 1, 2, 3], points: positions })逻辑说明：times数组必须和points一一对应，表示每个点对应的“时间刻度”。你可以不写 0、1、2、3 这种等差的时序，而是按实际飞行距离给每个点分配不同的时间值。比如直行段距离长、时间跨度和转弯段距离短、时间跨度短，这样速度就能自然调节。
参数说明：CatmullRomSpline的firstTangent和lastTangent是可选的，分别用于控制起点和终点的切线方向。如果你希望起飞时是垂直向上的，就在起点设一个朝上的切向量；希望落地前是平缓下滑的，就在终点设一个水平切向量。我通常会在首尾各设置一个 tangent，否则默认算法会让起点和终点处出现一段奇怪的加速曲线。
3.3 地形采样：路径必须贴着地形走
设计路径时最容易忽略的是地形高度变化。你用手工点的方式在二维地图上画了一条路线，高度全部填 200 米，但真实地形可能中间有一个 300 米高的山包，相机就会从山里穿过去，画面变成一片土黄色或直接闪到地下。
解决方法是做“地形采样”。利用 Cesium 的sampleTerrainMostDetailed把每个路径点的高度替换成真实地形高度，再叠加一个你期望的离地高度偏移量：
const positions = [ Cesium.Cartesian3.fromDegrees(116.391, 39.907), Cesium.Cartesian3.fromDegrees(116.396, 39.909), Cesium.Cartesian3.fromDegrees(116.398, 39.907) ] // 先把经纬度坐标转为 Cartographic const cartographics = positions.map(p => { const carto = Cesium.Cartographic.fromCartesian(p) return Cesium.Cartographic.fromDegrees( Cesium.Math.toDegrees(carto.longitude), Cesium.Math.toDegrees(carto.latitude) ) }) Cesium.sampleTerrainMostDetailed(viewer.terrainProvider, cartographics) .then((updatedCartographics) => { const adjusted = updatedCartographics.map(c => { return Cesium.Cartesian3.fromDegrees( Cesium.Math.toDegrees(c.longitude), Cesium.Math.toDegrees(c.latitude), c.height + 150 // 离地 150 米，避免地形遮挡 ) }) // 用 adjusted 重新创建 CatmullRomSpline })逻辑说明：sampleTerrainMostDetailed异步获取地形高度，回调里拿到的cartographic.height是真实海拔。对它加上一个安全偏移量之后，路径点才可用于飞行插值。这个偏移量不要统一写死，要在起伏大的区域用小偏移（30~50 米）以贴近地形看细节，在平坦区域用大偏移（100~200 米）让视野开阔。
参数说明：sampleTerrainMostDetailed对请求次数有限制，一次传几百个点没问题，但不要频繁调用。如果你的路径点超过 500 个，建议先做抽稀或分块采样。另外，terrainProvider必须在创建 viewer 时就指定好地形数据，默认的 EllipsoidTerrainProvider 是光滑椭球面，没有真实地形高度，采样结果会出现“全部是 0”的情况，导致路径点落入地下。
3.4 路径可视化：调试时把路径画出来
路径设计完以后，一定要先把它渲染出来看一眼再跑动画。这一步能帮你抓住 80% 的穿地和突刺问题。我在每次做飞行漫游的第一步就是先在场景里画一条 polyline，然后沿着 polyline 撒几个 billboard 作为途经点标记：
const polyline = viewer.entities.add({ polyline: { positions: adjustedPositions, width: 4, material: Cesium.Color.YELLOW.withAlpha(0.8), clampToGround: false } }) adjustedPositions.forEach((p, index) => { viewer.entities.add({ position: p, point: { pixelSize: 8, color: Cesium.Color.CYAN } }) })逻辑说明：clampToGround: false意味着线条保持你设定的三维坐标，不贴地。这样你能直观看到路径在立体空间里的形状，检查有没有哪一段高度异常。把路径画出来之后，你还可以整体抬高路径高度——不用重新生成每个点，直接用矩阵变换把路径整体上移。
参数说明：clampToGround如果设为 true，polyline 会被压到地形上，完全失去你设定的高度信息。调试飞行路径时建议始终保持 false。pixelSize是 billboard 点的大小，设 8~12 像素在远距离下看得很清楚。用 CYAN 和 YELLOW 两种颜色区分路径线和采样点，比单色更直观。
提示：调试路径时把
viewer.clock.shouldAnimate设为 false，手动拖动时间轴逐帧查看相机位置的变化。这比直接播放动画更容易定位问题点。
4. 相机动画逐帧驱动：从 Spline 到 Camera 的映射逻辑
4.1 用 Clock.onTick 驱动：每一帧都重新计算相机姿态
路径有了，接下来就是逐帧驱动相机沿着路径移动。Cesium 的时钟系统viewer.clock提供了onTick事件，每一帧渲染前都会触发。在这个回调里，你需要根据当前时钟时间从样条曲线上取相机位置，再根据当前和下一帧的位置计算相机朝向，最后把结果赋给camera。
const startTime = Cesium.JulianDate.now() const duration = 60 // 秒 const stopTime = Cesium.JulianDate.addSeconds(startTime, duration, new Cesium.JulianDate()) viewer.clock.startTime = startTime.clone() viewer.clock.stopTime = stopTime.clone() viewer.clock.currentTime = startTime.clone() viewer.clock.clockRange = Cesium.ClockRange.CLAMPED viewer.clock.canAnimate = true viewer.clock.shouldAnimate = true viewer.clock.onTick.addEventListener(function (clock) { const elapsed = Cesium.JulianDate.secondsDifference(clock.currentTime, startTime) const t = elapsed / duration // 归一化时间 if (t < 0 || t > 1) return // 从样条曲线上取位置 const position = spline.evaluate(t) // 计算下一帧的位置，用于确定朝向 const tNext = Math.min(t + 0.005, 1) const positionNext = spline.evaluate(tNext) // 计算相机朝向：看前方路径点，而不是水平向前 const direction = Cesium.Cartesian3.subtract(positionNext, position, new Cesium.Cartesian3()) Cesium.Cartesian3.normalize(direction, direction) // 设置相机位置和朝向 viewer.camera.setView({ destination: position, orientation: { direction: direction, up: Cesium.Cartesian3.clone(Cesium.Cartesian3.UNIT_Z) } }) })逻辑说明：核心逻辑是把归一化时间 t 映射到样条曲线的evaluate方法上，得到相机在三维空间中的位置。setView在这里的作用是“硬设定”相机到指定位置和方向，不做插值动画。因为每帧都在设，帧率 60 的情况下视觉上就是连续动画。
参数说明：tNext的0.005是经验值，它决定了朝向计算的“预视距离”。太大会导致转弯时朝向滞后，太小会导致相机朝向抖动。实际上这个值应该和飞行速度联动：速度越快，预视距离越大。如果你需要精确控制，可以在路径设计中记录每个时间点的速度，然后动态计算tNext。
4.2 朝向计算：direction 和 up 到底怎么定
上面代码里相机朝向用的是direction = positionNext - position，即“看向路径前方”。这在飞行场景中是合理的——相机的视线方向与运动方向一致，就像坐在车头往前看。但巡检场景里我们往往不是“往前看”，而是“往侧下方看”——比如查看大坝坝面或边坡时，视线应该偏向路径的一侧，这就是“动态朝向”的问题。
常见做法是：先计算路径的切线方向作为 forward 向量，再用叉积求出“右向”和“上向”，然后用三角函数让视线方向在 forward 和 right 之间做偏移。下面这段代码实现了一个向路径右侧偏 30 度的观察方式：
function getCameraOrientation(position, positionNext, pitchOffset) { const forward = Cesium.Cartesian3.subtract(positionNext, position, new Cesium.Cartesian3()) Cesium.Cartesian3.normalize(forward, forward) const up = Cesium.Cartesian3.clone(Cesium.Cartesian3.UNIT_Z) const right = Cesium.Cartesian3.cross(forward, up, new Cesium.Cartesian3()) Cesium.Cartesian3.normalize(right, right) // 视线从 forward 方向水平向右偏 30 度 const angle = Cesium.Math.toRadians(30) const lookDir = Cesium.Cartesian3.lerp(forward, right, Math.sin(angle), new Cesium.Cartesian3()) Cesium.Cartesian3.normalize(lookDir, lookDir) // 添加俯仰角：向下看或平视 const finalDir = Cesium.Cartesian3.lerp(lookDir, up, Math.sin(pitchOffset), new Cesium.Cartesian3()) Cesium.Cartesian3.normalize(finalDir, finalDir) return { direction: finalDir, up: Cesium.Cartesian3.clone(up) } }逻辑说明：先算出路径的 forward 向量和 right 向量，然后用lerp在 forward 和 right 之间做一个矢量插值。Math.sin(angle)作为插值系数，角度为 0 时视线朝前，角度 90 度时视线完全朝右。之后再用同样的方式在水平视线和竖直向上之间做俯仰插值。两个插值叠加后，视线就变成了“向右偏 30 度 + 向下看 20 度”的斜向观察视角。
参数说明：pitchOffset是俯仰偏量，传Math.toRadians(-20)表示向下看 20 度，传正值则抬头。注意lerp得到的向量必须在最后做normalize，否则相机朝向会带上非单位向量的问题，导致画面畸变。
4.3 速度控制：匀速飞行 vs 关键点停留
匀速飞行的实现上面已经给出了。但如果巡检要求在每个设施点停留 3 秒看一眼，就要在路径里加入“停留段”。有两种常见做法。第一种是改 times 数组——让两个位置点对应同一个或非常接近的时间，这样相机运动到该点后几乎不动：
// 路径点：A -> B -> C，在 B 点停留 3 秒 const times = [0, 0.4, 0.4, 1] const points = [ Cesium.Cartesian3.fromDegrees(116.391, 39.907, 200), Cesium.Cartesian3.fromDegrees(116.393, 39.908, 220), Cesium.Cartesian3.fromDegrees(116.393, 39.908, 220), Cesium.Cartesian3.fromDegrees(116.396, 39.909, 260) ]逻辑说明：times 里0.4出现了两次，对应的位置都是同一个点。Catmull-Rom 插值遇到重复时间点时，在该处会形成一个“暂停”，相机会在 B 点停住。但因为 Catmull-Rom 算法本身对重复时间点的处理会导致速度不连续，暂停结束后会有一段加速过程。
参数说明：这种方法的缺点是暂停的“停”不够干脆，会有微小的漂移。更稳妥的做法是拆分动画：飞到 B 点后用viewer.clock.shouldAnimate = false暂停时钟，3 秒后再设回 true 并继续。我一般用后一种，因为你可以利用暂停时间做更多动作，比如切换巡检标注信息。
4.4 停止与重置：给漫游一个刹车
飞行漫游的结束处理很容易被忽略。动画到终点后，相机应该停在一个合理的观察位置上，而不是悬在最后一个路径点的半空中继续晃。同时时钟要复位，否则用户手动拖地图时相机会被 onTick 里的 setView 强制拉回。
function stopFlight() { viewer.clock.shouldAnimate = false viewer.clock.onTick.removeEventListener(onTickCallback) // 重置相机变换矩阵，解除漫游锁定 viewer.camera.lookAtTransform(Cesium.Matrix4.IDENTITY) // 把相机放在终点附近，朝一个概括性视角看下去 const endCarto = Cesium.Cartographic.fromCartesian(spline.evaluate(1)) viewer.camera.setView({ destination: Cesium.Cartesian3.fromDegrees( Cesium.Math.toDegrees(endCarto.longitude), Cesium.Math.toDegrees(endCarto.latitude), endCarto.height + 200 ), orientation: { heading: 0, pitch: Cesium.Math.toRadians(-30), roll: 0 } }) }逻辑说明：removeEventListener必须传原来的回调引用，所以在注册 onTick 时要把回调函数单独保存为变量。lookAtTransform(Matrix4.IDENTITY)是释放之前所有 lookAt 锁定的标准做法。
参数说明：复位后的setView不是为了继续飞，而是为了把镜头放在一个舒服的总结视角。heading 设 0 表示正北方向，pitch -30 度让视野往下倾斜 30 度，看终点的全局情况。这个视角不要和飞行视角差异太大，否则用户会感觉“突然闪了一下”。
5. 漫游避坑指南：地形穿模、相机抖动和交互冲突的三类实战问题
5.1 相机穿地：画面突然变成一片土黄色
现象：飞行过程中画面在某一段突然看不到场景，而是显示地形的内部颜色或者直接变成黑色。
原因：最常见的就是路径点高度低于地形高程。也就是你编写路径点时没有做地形采样，或者采样后的偏移量过小，插值曲线在两点的中间段穿过了山脊。还有一个原因是CatmullRomSpline插值时端点切线方向朝下，导致曲线在端点附近形成一个低垂的弧度，即使端点本身高出地面，中间段仍然触地。
解决：首先确保每个路径点都做了sampleTerrainMostDetailed采样。然后在每个点的高度上加一个安全冗余，常规场景加 50~100 米，地形起伏大的区域加 150~300 米。最后，检查 spline 的firstTangent和lastTangent，确保起点切线朝上或水平，不要朝下。如果还穿，就在可疑区域加密路径点，加密后的 Catmull-Rom 曲线会更贴合你预设的高度走廊。
5.2 转弯时相机抖动：画面在拐角处出现高频震颤
现象：直线飞行正常，一到转弯处画面就开始小幅度左右抖动，像视频里加了震动特效。
原因：转弯时路径曲率变大，tNext预视距离固定不变导致朝向计算出现“过冲”。具体来说，在弯道处 spline 的切线方向变化很快，你用固定的t + 0.005取下一帧位置，前后两帧的位置连线可能偏离真实切线方向很大，换算成朝向角的变化会一帧大、一帧小，视觉上就是抖动。
解决：把固定的tNext改为动态计算。方法是先根据当前飞行速度估算出每帧前进的欧氏距离，然后设定一个固定的“视距”（比如 30 米），反推 t 的增量：
const speed = 100 // 米/秒 const frameInterval = 1 / 60 // 假设 60 帧 const stepDistance = speed * frameInterval // 粗略估算当前速度下 t 每帧的增量 const tStep = stepDistance / totalPathLength const tNext = Math.min(t + Math.max(tStep * 3, 0.01), 1)逻辑说明：tStep乘以 3 是让视野范围超出实际行进距离，给相机朝向一个“预视”的余量。在弯道处，这个余量让朝向变化更平缓，不会贴着切线左右摆。你可以把这几个参数打印出来对比抖动前后弯道处的取值变化。
参数说明：speed应使用 path 设计时的实际速度。如果你的动画时长和路径长度的比是 60 秒飞 6 公里，那平均速度就是 100 米/秒。把 speed 和 totalPathLength 打印到控制台，可以减少很多盲猜。
5.3 用户拖拽后镜头被拉回：漫游和手动交互的冲突
现象：飞行漫游过程中，用户想拖动鼠标看路边的一栋楼，结果手一松，镜头瞬间被拉回原来的飞行路径上。
原因：onTick回调里每帧执行camera.setView，这个操作会无条件覆盖相机状态，包括用户通过鼠标交互对相机作的修改。Cesium 的鼠标控制本质上也是改 camera，但它是增量式的修改；你的 setView 是重置式修改，两者冲突时你这边赢，所以用户拖完马上被拽回来。
解决：加入一个“用户干涉”标志位。监听场景的鼠标事件，在漫游中如果用户触发拖拽，就暂停自动飞行，把控制权交给用户：
viewer.screenSpaceEventHandler.setInputAction(function () { if (isFlying) { stopFlight() } }, Cesium.ScreenSpaceEventType.LEFT_DOWN) viewer.screenSpaceEventHandler.setInputAction(function () { if (isFlying) { stopFlight() } }, Cesium.ScreenSpaceEventType.MOUSE_MOVE) // 仅当 LEFT_DOWN 时触发逻辑说明：LEFT_DOWN事件表示用户按下了鼠标，这时候应该立刻停掉自动漫游。这比等用户拖完再判断好得多，因为 LEFT_DOWN 的瞬间用户就已经表达了对当前自动控制的不满。MOUSE_MOVE 事件的回调里要判断是否按下左键，否则鼠标在场景里飘过也会触发暂停，误伤率太高。
参数说明：这种方案等于把“停止漫游”的操作权重给了用户。飞行的结束状态可以用 4.4 里的 stopFlight 函数来接管，让相机平稳复位。如果你希望用户释放鼠标后能“继续自动驾驶”，那需要在 mouse up 时重新从当前相机位置计算新的路径继续飞行，实现起来要额外做一个“接续路径”的逻辑，工作量大不少，不太建议第一版做。
5.4 飞行结束后视角被锁定：lookAtTransform 忘记重置
现象：漫游结束后，用户拖动鼠标发现场景完全无法旋转，像是被钉死了一样。
原因：在路径设计时为了从固定角度观察某个点，你调用过camera.lookAt或者lookAtTransform设置了观察矩阵。飞行结束后如果没有重置这个矩阵，相机就一直保持“锁定目标点”的状态，任何交互都失效。
解决：在所有结束路径的代码里，强制把 lookAtTransform 重置为Matrix4.IDENTITY放在第一步。也就是不管什么原因导致漫游结束（自然结束、用户打断、代码异常），都要在停止逻辑的第一行执行这个重置。你可以把 stopFlight 函数里的一行提到最前面。
6. 进阶技巧：把速度曲线揉进路径，让飞行像“有经验的驾驶员”操作
自动漫游最容易看出“机器感”的地方是速度：起飞和停止都很突兀，转弯也不减速。一个简单的改进是给速度加一个梯形斜坡——起飞时从 0 加速到巡航速度，结束前提前减速，转弯段按曲率自动降速。实现上不需要改插值算法，只改 times 数组的分配逻辑即可。
方法如下：先把路径的累计长度算出来，然后把它离散成 N 个采样点，给每个点分配一个“设计速度”。速度在进入转弯前线性递减，出弯后线性递增。最后用每个采样点的路径距离除以该处速度，得到每段所需时间，累加就得到最终 times 数组：
function buildTimesWithSpeed(points, speeds) { let cumulativeDistance = 0 const distances = [] for (let i = 1; i < points.length; i++) { const d = Cesium.Cartesian3.distance(points[i - 1], points[i]) cumulativeDistance += d distances.push(cumulativeDistance) } const times = [0] let elapsed = 0 for (let i = 0; i < distances.length; i++) { const segSpeed = (speeds[i] + speeds[i + 1]) / 2 // 平均速度 const segTime = (distances[i] - (i > 0 ? distances[i - 1] : 0)) / segSpeed elapsed += segTime times.push(elapsed) } const total = times[times.length - 1] return times.map(t => t / total) // 归一化到 [0, 1] }逻辑说明：每个采样点对应一个设计速度，段速度取两端的平均值，时间等于距离除以平均速度。这样一个弯道密集的路径，每个点的 time 间隔会比较大，插值后的曲线在时间轴上自动实现“转弯时慢、直行时快”的效果。
参数说明：speeds数组的长度必须和points一致，每个速度值单位是米/秒。设计速度的赋值没有绝对标准，但有几个经验值可以参考：平直路段设 80~150 米/秒，转弯段设 30~60 米/秒，靠近观察点时设 10~20 米/秒。你可以在场景里用 speed 标签可视化每一段的速度，调整到看起来“舒服”为止。
另外还有一个很容易被忽视的技巧：飞行中相机的 up 向量不要一直用 UNIT_Z。当路径接近竖直方向时（比如从山顶俯冲到山谷），UNIT_Z 和 forward 方向夹角太小，叉积结果不稳定，画面会突然翻转。解决方法是动态切换 up 向量——当 forward 与 UNIT_Z 夹角小于 30 度时，改用相机的历史 up 向量插值过渡，而不是直接跳：
function computeUpVector(forward, lastUp) { const angle = Cesium.Math.acosClamped( Cesium.Cartesian3.dot(forward, Cesium.Cartesian3.UNIT_Z) ) if (Cesium.Math.toDegrees(angle) > 30) { return Cesium.Cartesian3.clone(Cesium.Cartesian3.UNIT_Z) } // 用上一个 up 向量的垂直分量平滑过渡 const right = Cesium.Cartesian3.cross(forward, lastUp, new Cesium.Cartesian3()) const newUp = Cesium.Cartesian3.cross(right, forward, new Cesium.Cartesian3()) return Cesium.Cartesian3.normalize(newUp, newUp) }逻辑说明：acosClamped是 Cesium 提供的一个安全的反余弦函数，输入被限制在 [-1, 1] 区间，避免因浮点误差出现 NaN。如果 forward 接近竖直方向，就用 lastUp 重新做一次正交基构建，得到一个新的 up。this 的 lastUp 在每帧渲染时更新为上一帧的 up 值。
从那以后我每次做 Cesium 飞行漫游，都会强制自己走一遍这个流程：画路径、采样地形、可视化检查、预演速度曲线、加用户中断处理。这套流程看着多，但能在一开始挡住绝大部分穿地和眩晕问题。动画这种东西，做出来“能跑”容易，做出来“能用”就得靠这些细节一点一点堆。希望帮到你。
本文还有配套的精品资源，点击获取
