Angular 版本更新实战：ng update 命令、版本化策略与支持周期完整指南

Angular 与整个 Web 生态一样处于持续演进之中，官方在“持续改进”与“稳定可靠”之间寻求平衡，因此保持应用与库的及时更新是享受新特性、性能优化和缺陷修复的前提。本文基于 Angular 官方仓库中的最佳实践文档 Keeping your Angular projects up-to-date，完整覆盖“获取版本通知—检查当前版本—执行 ng update 更新—理解版本化与升级路径”的全流程，并结合 CLI update 命令参考、Angular versioning and releases 以及仓库内的 CHANGELOG 和 core schematics 迁移配置，从实操命令到版本化机制给出可落地、可验证的更新方案。

更新 Angular 的总体思路

官方文档开宗明义：Angular 在持续改进的同时高度重视稳定性，并让“更新”这件事本身尽量简单。保持应用更新到位的价值在于：

• 第一时间获得前沿新特性（leading-edge features）；
• 拿到官方优化与 bug 修复；
• 遵循可预期的版本化与弃用节奏，降低技术债累积风险。

文档同时区分了两类读者路径：

• 如果你使用的是 Angular v2+（现代 Angular），本文的 ng update 流程与 版本化策略 完全适用；
• 如果你仍在使用 AngularJS（即 v1.x 版本），则应走专门的“从 AngularJS 升级”路径，官方文档明确提示这一区别。

获取新版本的发布通知

要在新版本发布时及时得知，官方给出两个渠道：

• 在 X（原 Twitter）上关注 Angular 官方账号；
• 订阅 Angular 官方博客，其中会发布 release announcements（发布公告）。

发布公告侧重于“这次发布有什么重要变化、你需要知道什么”；而想要逐条查看按版本组织的完整变更明细，则应查阅 Angular change log。在当前仓库中，这份变更日志就是根目录下的 CHANGELOG.md，其当前最新版本条目为 22.2.0-next.4 (2026-08-26)，并按 common、compiler、compiler-cli、core、forms 等包分节列出每个 commit 的类型（feat/fix）与描述——这正是“按版本组织的完整变更清单”的实体。

检查你当前使用的 Angular 版本

在动手升级前，先明确自己所处的位置。文档给出的标准做法是：

ng version

在项目目录内执行 ng version 即可查看当前应用所使用的 Angular 版本。该命令同样是 CLI 命令参考 的一部分。

确认 Angular 当前最新版本

有两条途径确认最新的稳定版：

1. npm：@angular/core 包在 npm 上的 "Version" 字段即为最新稳定版（文档以 16.2.4 为例，具体数值以 npm 实时页面为准）。
2. CLI：直接运行不带任何参数的 ng update。默认情况下，无参 ng update 不会立即改动项目，而是列出你可用的更新并给出推荐的升级步骤——这使它成为“体检 + 升级方案预览”二合一的工具。

执行更新：ng update 命令详解

对于简单更新，ng update 一条命令即可胜任。下面结合 CLI update 命令的完整定义（其中包含官方 long description 与全部选项定义）展开。

基本更新

更新到核心框架与 CLI 的当前稳定版：

ng update @angular/cli @angular/core

要点：从 Angular 7 开始，@angular/core 与 @angular/cli 的主版本号保持对齐，更新时应同时指定这两个包，保证二者版本一致。

更新到预发布版本

使用 --next 选项可更新到下一个 beta 或预发布版本（对应 next/rc 预发布通道，见下文版本化说明）：

ng update @angular/cli @angular/core --next

跨大版本更新

跨 major 版本更新采用带版本范围的写法：

ng update @angular/cli@^<major_version> @angular/core@^<major_version>

官方明确建议：始终更新到最新 patch 版本，因为它包含初始大版本发布后陆续发布的修复。例如要升级到 21.x 最新 patch 版：

ng update @angular/cli@^21 @angular/core@^21

完整选项参考

以下参数表整理自 update.json 中的 options 定义，可作为 ng update 的完整选项参考：

选项	类型	默认值	说明
packages	array	[]	要更新的包名（位置参数，可传多个）
allow-dirty	boolean	false	允许在仓库存在已修改或未跟踪文件时执行更新
create-commits（别名 -C）	boolean	false	为更新和迁移操作创建源码控制提交
force	boolean	false	忽略 peer dependency 版本不匹配
from	string	—	迁移起始版本；仅在更新单个包且配合 migrate-only 时可用
to	string	检测到的已安装版本	迁移目标版本；仅配合 migrate-only 且指定 from 时可用
migrate-only	boolean	—	只执行迁移，不更新已安装版本
name	string	—	要运行的迁移名称；仅在更新单个包时可用
next	boolean	false	使用预发布版本（含 beta 与 RC）
verbose	boolean	false	显示执行期间内部操作的更多细节
help	boolean	—	在控制台显示帮助信息

from / to / name 这组选项构成“只跑迁移不升版本”的精细控制场景：当版本升级与代码迁移需要分步进行、或某次迁移需要单独重试时，可以指定迁移区间（--migrate-only --from X --to Y）或按名称指定单个迁移（--name）执行，而不触碰依赖版本。

版本化与发布节奏：更新前必须理解的规则

Angular versioning and releases 描述了版本号含义、支持窗口与升级路径，是决定“现在该不该升、能升到哪里”的依据。

语义化版本号

Angular 采用 major.minor.patch 三段式语义化版本，各段含义与开发者预期工作量如下表（原文档完整保留）：

变更级别	说明
Major 发布	包含重大新特性，更新时需要少量但必要的开发者参与：可能需要运行更新脚本、重构代码、补充测试并学习新 API
Minor 发布	包含较小新特性，完全向后兼容，更新不需要开发者参与；可选择性地开始使用新 API。Minor 版本中 peer 依赖只会“扩大支持范围”，不强制项目升级
Patch 发布	低风险 bug 修复版本，更新不需要任何开发者参与

预发布版本

每个 major 与 minor 发布都会提供两类预发布：

预发布类型	说明
Next	正在积极开发与测试中的下一个版本，版本标签带 -next 后缀，如 8.1.0-next.0
Release candidate	功能完备、处于最终测试阶段，版本标签带 -rc 后缀，如 8.1.0-rc.0

这与 ng update 的 --next 选项直接对应：该选项会选中最新的 next 或 rc 预发布版本。

发布频率与当前支持状态

自 v22 起（此前的版本采用 6 个月一个大版本、每大版本 1–3 个 minor 的节奏），官方给出的发布周期为：

• 每 12 个月 一个 major 发布；
• 每个 major 包含 4–6 个 minor 发布；
• 几乎每周 有一个 patch 发布与预发布（next 或 rc）构建。

当前处于支持期的版本状态（引自 releases.md）：

版本	状态	发布时间	Active 结束	LTS 结束
^22.0.0	Active	2026-06-03	2027-06	2028-06
^21.0.0	LTS	2025-11-19	2026-06-03	2027-06
^20.0.0	LTS	2025-05-28	2025-11-19	2026-11-28

v2 至 v19 已不再受支持。所有 major 版本通常支持 24 个月：前 12 个月为 Active（按计划定期发布更新与补丁），后 12 个月为 LTS（仅发布关键修复与安全补丁）。LTS 阶段的修复准入条件是：新发现的安全漏洞，或自 LTS 开始以来由第三方变化（如新浏览器版本）引起的回归。

计划中的发布日程（日期为大致指引，可能调整）：

版本	预计时间
v22.1	2026-07-27 当周
v22.2	约 2026 年 9 月
v22.3	约 2026 年 11 月
v22.4	约 2027 年 1 月
v22.5	约 2027 年 3 月
v23.0	约 2027 年 6 月

弃用策略与合法的升级路径

弃用（Deprecation）策略

当某个 API 过时、被新 API 取代或停止维护时会被标记为 deprecated，且弃用期至少跨越一个 major 版本（约一年）。策略分为三块：

• Announcement（宣布）：被弃用的 API 会在 change log 中宣布、在 API 文档中以删除线呈现，并附带推荐更新路径；源码中的弃用 API 会标注 @deprecated，使编辑器与 IDE 能对依赖它们的代码给出提示。
• Deprecation period（弃用期）：被弃用的 API 至少保留到下一个 major 发布之后，之后才成为移除候选。弃用可以在任意版本宣布，但移除只发生在 major 发布中。弃用未移除期间，该 API 按 LTS 策略维护（只修关键与安全问题）。
• npm 依赖：需要改动应用代码的 npm 依赖更新只出现在 major 发布中；minor 发布只是扩大 peer 依赖的兼容范围，不强制升级。

ng update 的升级路径约束

官方文档明确了 ng update 能到达的边界，必须同时满足两条：

1. 你更新到的版本处于受支持状态；
2. 你更新自的版本与目标版本相差不超过一个大版本。

例如可以从 11 升到 12（前提是 12 仍在支持期内）。需要跨多个 major 时，必须逐个大版本推进，例如从 10 到 12 应：

1. 先从 10 更新到 11；
2. 再从 11 更新到 12。

官方为这套路径提供三层支撑：移除公开 API 前遵循弃用策略；ng update 提供代码转换（migration）自动化，这些转换脚本“通常已在 Google 内部数十万个项目上预先测试过”；交互式 Angular Update Guide（对应仓库中的 update 功能组件，按用户给定的起始/目标版本生成定制化的更新说明）提供从一个大版本到另一个大版本的逐步操作指引。

迁移机制的仓库侧佐证：schematics 迁移集合

ng update 之所以能“自动改代码”，底层依赖的是各包内置的迁移集合。在当前仓库中，packages/core/schematics 目录下的 migrations.json 与 collection.json 正是 @angular/core 的迁移注册入口：migrations.json 按版本区间声明迁移任务，collection.json 定义 schematics 集合。结合 update.json 中 migrate-only、from、to、name 四个选项的存在，可以推断 ng update 在执行时会解析这些注册表，按版本区间挑选应执行的迁移并逐个应用到项目上——这也解释了为什么“只跑某个迁移、不升版本”是被官方支持的操作模式。

此外，releases.md 的兼容性策略一节还说明：为保证向后兼容，任何改动合并前都会经过单元测试、集成测试、公共 API 类型定义前后比对，以及在 Google 内部所有依赖 Angular 的应用上运行测试——这些是“minor/patch 可以无感升级”这一承诺的工程保障。

资源小结

沿用原文档的 Resource summary，并将指向仓库内资源的条目转换为仓库相对路径，便于直接查阅：

• 发布公告：Angular 官方博客的 release announcements（外部渠道，以官方渠道实时内容为准）；
• 发布明细：CHANGELOG.md（按版本组织，按包分节）；
• 更新说明：交互式 Angular Update Guide，仓库内实现见 update.component.ts，提供基础与进阶两条更新路径、故障排查信息与推荐的手工改动；
• ng update 命令参考：cli/update.json；
• 版本化、发布、支持与弃用实践：reference/releases.md；
• 本文主体文档：best-practices/update.md。