0. 为什么我们的项目选择 Cesium：从三维地图、离线部署到工程代价

前言

最近实习在做一个和无人机、任务调度、事件点位相关的前端项目，项目里需要展示地图、区域边界、点位标记等能力。

一开始很多人想到的可能是高德地图、百度地图、腾讯地图这类 Web 地图 SDK。它们上手快、生态成熟和路径规划能力完整，对于普通位置展示、路线规划、搜索查询类业务非常合适。

但这个项目场景有点不一样：

• 项目存在内网、专网或弱外网环境部署的可能。
• 不希望核心地图能力强依赖外部在线服务。
• 高德这类平台通常需要申请 Key，商业使用、调用配额、服务能力也会受平台规则约束。

所以最后项目里选择了 Cesium。

需要先说明一点：Cesium 并不是"自带所有离线地图数据"的地图平台。更准确地说，Cesium 是一个三维地理空间可视化引擎。它支持加载本地或远程的影像、地形、3D Tiles、GeoJSON、KML/KMZ 等数据。如果我们把 Cesium 运行库、地图瓦片、模型、地形等资源部署到自己的服务器或内网环境里，就可以做到更可控的离线或内网地图方案。

这篇文章主要聊聊：

• Cesium 是什么。
• Cesium 有哪些优势。
• 为什么我们的项目不用高德，而选择 Cesium。
• Cesium 在前端工程里的使用方式。
• Cesium 的缺点和踩坑点。

Cesium 是什么

CesiumJS 是一个开源的三维地理空间可视化 JavaScript 库，主要用于在浏览器中展示 3D 地球、2D 地图、地形、影像、3D Tiles、轨迹、模型、点线面等空间数据。

你可以把它理解成：

Cesium = 浏览器里的三维地图/数字地球渲染引擎

它不是单纯的"地图 SDK"，而是更偏向底层和可视化能力的地理空间引擎。

普通地图 SDK 更擅长：

• 地址搜索
• 路线规划
• 地理编码
• 行政区查询
• 在线底图服务

Cesium 更擅长：

• 三维地球展示
• 地形渲染
• 3D Tiles 数据加载
• 倾斜摄影、BIM、城市模型展示
• 经纬度和三维空间坐标转换
• 飞行轨迹、航线、点位、区域可视化
• KML、KMZ、GeoJSON 等地理数据加载
• 内网或离线环境下的自托管地图能力

所以，如果你的业务只是"展示一个门店位置"，用高德会更快。

但如果你的业务是"展示无人机航线、飞行轨迹、三维场景、任务区域、空间数据"，Cesium 会更合适。

我们项目里为什么需要 Cesium

我们的项目中有很多和地图相关的业务模块，比如：

• 无人机任务调度
• 飞行轨迹展示
• 事件点位展示
• 区域边界展示
• 任务对象位置展示
• 成果分析大屏

在代码里，我们会用到 Cesium 的这些能力：

new Cesium.Viewer(...)

用于创建三维地图容器。

Cesium.Cartesian3.fromDegrees(lng, lat)

用于把经纬度转换成 Cesium 的三维坐标。

Cesium.WebMapTileServiceImageryProvider

用于加载瓦片底图服务。

Cesium.KmlDataSource.load(...)

用于加载 GeoJSON 区域边界数据。

Cesium.ScreenSpaceEventHandler

用于处理地图点击、拾取实体等交互。

这些能力不是普通 UI 组件库能提供的，也不是 ECharts 地图可以轻松替代的。ECharts 更适合统计图、二维地图可视化；Cesium 更适合真实地理空间和三维场景。

为什么没有直接使用高德地图

高德地图当然很好用。对于很多普通业务系统来说，高德 Web JS API 上手更快，文档也成熟，常见能力都比较完整。

但是在我们的项目里，高德不是最优选择，主要原因有几个。

1. 高德需要申请 Key

使用高德 Web 服务或 Web JS API，一般都需要在开放平台创建应用并申请 Key。

这本身不是问题，几乎所有商业地图平台都会这么做。Key 的作用是：

• 标识调用方身份。
• 做访问控制。
• 做用量统计。
• 做配额管理。
• 做安全域名限制。

但是这也意味着项目对平台账号和 Key 体系有依赖。

如果是公网项目，这种方式很正常；但如果是内网、专网、私有化部署项目，Key 管理、域名绑定、环境迁移、调用限制都会变成额外成本。

2. 商业使用和调用配额需要考虑成本

高德这类地图平台通常会区分不同服务类型、调用量、商业授权或配额规则。对于企业项目，尤其是正式商用、政企项目、私有化部署项目，不能只看"开发时能免费调用"，还要考虑：

• 调用量是否超限。
• 商业授权是否满足。
• 是否依赖在线服务。
• 是否需要额外购买服务。
• 是否能在客户内网环境稳定访问。

如果项目规模变大，地图调用量上来之后，这些都可能变成实际成本。

所以我们不能简单地把高德当成"永远免费"的底图能力。

3. 高德更偏在线地图服务

高德的优势是在线地图生态，包括：

• 在线底图
• POI
• 地址搜索
• 路径规划
• 逆地理编码
• 实时路况

但这些能力高度依赖在线服务。

而我们的项目更关注：

• 内网环境能不能跑。
• 地图底图能不能自托管。
• 轨迹、航线、区域等业务数据能不能自己控制。
• 三维场景能不能深度定制。

这时 Cesium 的自托管能力更有吸引力。

4. Cesium 更适合三维地理空间场景

高德也有 JS API，也能做点线面覆盖物，也有一些 3D 能力。但如果业务核心是三维空间数据，Cesium 的能力边界更合适。

比如：

• 三维地球
• 地形
• 倾斜摄影
• 3D Tiles
• KML/KMZ
• GeoJSON
• 相机飞行
• 空间实体管理
• 三维点线面绘制

这些都是 Cesium 的主场。

Cesium 的优势

1. 支持三维地球和真实空间坐标

Cesium 最大的特点就是三维。

它不是简单地在平面地图上画点，而是在一个真实的三维地球场景中管理空间数据。

这对于无人机、航线、飞行轨迹、地形、倾斜摄影等业务非常重要。

比如无人机任务里，点位不只是：

经度、纬度

还可能涉及：

高度
航向
俯仰角
飞行轨迹
空间区域
视角控制

Cesium 对这些空间概念的支持更自然。

2. 适合加载多种地理数据格式

Cesium 支持很多地理空间数据格式，例如：

• KML
• KMZ
• GeoJSON
• CZML
• 3D Tiles
• glTF
• 地形数据
• 影像瓦片

在我们的项目中，飞行记录、航线文件、区域边界、任务点位都可以通过这些能力展示。

3. 可以自托管，适合内网和离线场景

这是我们选择 Cesium 的一个重要原因。

在项目中，我们可以把 Cesium 相关文件放到：

public/cesium

构建后会复制到：

dist/cesium

然后通过：

<link rel="stylesheet" href="/cesium/Widgets/widgets.css" />
<script src="/cesium/Cesium.js"></script>

从自己的服务器加载。

这意味着：

Cesium 运行库不依赖外部 CDN
地图资源可以部署到内网
业务数据可以完全走自己的接口
项目可以适配私有化部署

当然，真正的离线地图不只是放一个 Cesium.js 就够了，还需要准备离线影像瓦片、地形数据、模型数据等资源。

所以严格说：

Cesium 支持离线/内网地图方案
不等于 Cesium 自带完整离线地图数据

这是很多人容易误解的地方。

4. 可控性强

使用商业地图平台时，很多底层能力是平台封装好的。简单业务很舒服，但复杂业务容易受限制。

Cesium 更底层，意味着我们可以控制更多东西：

• 相机视角
• 图层加载
• 实体管理
• 点线面样式
• 轨迹动画
• 地图点击拾取
• 地形和模型
• 数据源加载方式
• 内网资源路径

对于复杂地图业务，控制能力很重要。

5. 适合大屏和可视化场景

Cesium 的三维地图效果更适合调度大屏、态势感知、空间分析类页面。

比如：

• 无人机分布
• 任务态势
• 飞行记录
• 区域覆盖
• 事件告警
• 航线回放

这些场景需要的不只是"一个地图背景"，而是一个可以承载业务数据的空间容器。

我们项目里的引入方式

目前项目里没有通过：

import * as Cesium from "cesium"

把 Cesium 交给 webpack 打包。

而是把 Cesium 放在：

public/cesium

然后在 public/index.html 中引入：

<link rel="stylesheet" href="/cesium/Widgets/widgets.css" />
<script src="/cesium/Cesium.js"></script>

这样做的结果是：

build 时 public/cesium 会原样复制到 dist/cesium
浏览器运行时通过 /cesium/Cesium.js 加载 Cesium
项目代码里可以直接使用全局 Cesium 对象

这种方式的好处是简单稳定。

Cesium 自身包含 Workers、Assets、Widgets、ThirdParty 等资源。如果直接交给 webpack 处理，需要额外处理静态资源路径、Worker 路径、CESIUM_BASE_URL 等配置。对于 Vue CLI 老项目来说，这类配置容易踩坑。

所以把 Cesium 作为静态资源部署，是一个比较现实的工程选择。

但放进 dist 不等于用户不用下载

这里有一个很重要的点。

很多人会问：

既然 Cesium 已经打进 dist 了，用户是不是就不用下载了？

不是。

dist 是部署到服务器上的静态文件目录。用户打开网页时，浏览器仍然要从服务器下载：

/cesium/Cesium.js
/cesium/Widgets/widgets.css

只是这个下载来源从外部 CDN 变成了你自己的服务器。

也就是说：

不用从外部平台下载
不等于浏览器不用下载

如果 Cesium.js 很大，首次访问仍然会影响首屏性能。

Cesium 的缺点

Cesium 能力很强，但代价也很明显。

1. 体积非常大

Cesium 最大的问题就是大。

在我们的构建产物里，Cesium.js 的体积非常明显：

dist/cesium/Cesium.js 约 13 MB+
gzip 后也有 2 MB+

这对首屏加载不友好。

如果直接在 index.html 里写：

<script src="/cesium/Cesium.js"></script>

那么不管用户打开的是地图页面还是普通管理页面，浏览器都会加载 Cesium。

这会导致：

登录页也加载 Cesium
系统管理页也加载 Cesium
非地图页面也承担地图库体积

所以更好的方式是：

Cesium 仍然放 public
但不要在 index.html 首屏加载
进入地图页面时再动态加载 /cesium/Cesium.js

这样可以减少非地图页面的首屏压力。

2. 学习成本高

Cesium 的概念比普通地图 SDK 多很多。

你需要理解：

• Viewer
• Scene
• Camera
• Entity
• DataSource
• ImageryProvider
• TerrainProvider
• Cartesian3
• Cartographic
• HeadingPitchRange
• ScreenSpaceEventHandler

对于只做过普通 Web 页面或二维地图的前端来说，上手成本不低。

比如普通地图上画一个点，可能只需要经纬度。

但在 Cesium 里，你经常要处理：

Cesium.Cartesian3.fromDegrees(lng, lat, height)

以及各种坐标转换。

这会增加开发复杂度。

3. Worker 和静态资源路径比较麻烦

Cesium 不是一个单文件库。

它运行时会依赖：

• Workers
• Assets
• Widgets
• ThirdParty

如果通过 webpack 直接引入，经常需要处理：

• Worker 文件复制
• 静态资源路径
• CESIUM_BASE_URL
• publicPath
• 构建工具兼容问题

这也是很多项目选择把 Cesium 放 public 的原因。

不是因为这种方式最优雅，而是因为它最稳定。

4. 不自带业务需要的地图数据

Cesium 是引擎，不是数据服务。

如果要做离线地图，你还需要准备：

• 离线影像瓦片
• 离线地形数据
• 行政区边界
• 业务点位
• 3D Tiles 模型
• KML/KMZ 文件
• GeoJSON 数据

Cesium 负责加载和渲染这些数据，但不会凭空提供所有数据。

所以如果有人说：

用了 Cesium 就有离线地图了

这个说法是不准确的。

更准确的是：

Cesium 支持离线地图方案，但地图数据需要自己准备和部署。

5. 普通业务可能用不上

如果你的项目只是：

• 展示公司位置
• 展示门店点位
• 做地址搜索
• 做路径规划
• 做行政区选择

那 Cesium 可能太重了。

这类场景用高德、百度、腾讯地图会更快。

Cesium 更适合空间可视化、三维场景、离线部署、复杂地理数据展示。

如果只是二维点位展示，强行上 Cesium 反而会增加成本。

6. 性能优化难度更高

Cesium 渲染的是三维场景，对浏览器、显卡、内存都有一定要求。

如果页面中实体过多、模型过大、瓦片层级太深，可能出现：

• 首屏慢
• 内存占用高
• 帧率下降
• 页面卡顿
• 老机器体验差

所以使用 Cesium 时，需要额外关注：

• 实体数量控制
• 图层按需加载
• 模型压缩
• 瓦片层级控制
• 销毁 Viewer
• 页面离开时释放资源
• 避免重复创建地图实例

这比普通 DOM 页面复杂得多。

7. 生态方向和普通前端不完全一样

Cesium 属于 GIS / 3D / WebGL 方向。

它涉及很多普通前端不常碰的知识：

• WebGL
• 经纬度坐标系
• 投影
• 地形
• 瓦片
• 空间数据格式
• 三维模型
• 相机控制

所以团队里如果没有 GIS 或地图经验，前期会有一定磨合成本。

Cesium 和高德怎么选

可以简单这样判断。

如果你的项目主要是：

• 地址搜索
• POI 检索
• 路径规划
• 普通点位展示
• 城市生活服务
• 打车、外卖、门店、物流基础地图

优先考虑高德这类成熟地图 SDK。

如果你的项目主要是：

• 三维地球
• 飞行轨迹
• 无人机航线
• 倾斜摄影
• 3D Tiles
• 内网部署
• 离线地图
• 空间数据可视化
• 大屏态势展示

可以考虑 Cesium。

一句话：

高德更像在线地图服务平台。
Cesium 更像三维地理空间渲染引擎。

它们不是完全替代关系，而是适合不同场景。

我们项目里的优化方向

目前项目里 Cesium 是在 index.html 里直接引入的：

<script src="/cesium/Cesium.js"></script>

这种方式简单，但会导致所有页面首屏都加载 Cesium。

后续更合理的优化是：

保留 public/cesium 静态部署方式
移除 index.html 中的 Cesium 全局 script
封装 loadCesium 方法
只在地图页面进入时动态加载 Cesium.js

总结

我们项目选择 Cesium，主要不是因为它比高德更简单，而是因为业务场景更适合它：

• 需要三维地图能力。
• 需要展示无人机航线、飞行轨迹、事件点位、区域边界。
• 需要更强的空间数据可视化能力。
• 需要适配内网或离线部署。
• 不希望核心地图能力强依赖外部在线地图平台。
• 高德这类平台需要 Key，商用、配额、调用成本和外部服务依赖都需要考虑。

Cesium 的优势是能力强、可控性高、适合三维地理空间场景，也适合内网自托管。

但它的缺点也很明显：

• 体积大。
• 上手难。
• 静态资源路径复杂。
• 不自带地图数据。
• 对性能优化要求高。
• 普通二维地图业务可能没必要用它。

所以选择 Cesium 的前提不是"它免费"或者"它离线"，而是：

你的业务是否真的需要三维空间能力、自托管能力和复杂地理数据展示能力。

如果需要，Cesium 很值得。

如果只是普通地图点位展示，高德这类在线地图 SDK 可能更省事。

技术选型不是看哪个工具更强，而是看哪个工具更符合项目约束。

在我们的项目里，Cesium 的工程复杂度是可以接受的，因为它换来了更强的地图可控性、三维展示能力和内网部署能力。

参考

• CesiumJS 官方文档：cesium.com/learn/cesiu...
• CesiumJS GitHub：github.com/CesiumGS/ce...
• 高德开放平台：lbs.amap.com/