企业官网建设流程全解析

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

【免费下载链接】angularDeliver web apps with confidence 🚀项目地址: https://gitcode.com/GitHub_Trending/an/angular

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的完整选项参考：

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

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

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

语义化版本号

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

预发布版本

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

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

发布频率与当前支持状态

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

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

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

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

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

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

弃用（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。

【免费下载链接】angularDeliver web apps with confidence 🚀项目地址: https://gitcode.com/GitHub_Trending/an/angular