Angular 改为一年一个主版本：慢下来，是为了走得更稳
如果你最近关注 Angular 的版本发布，可能已经注意到一个变化：从 v22 开始，Angular 的主版本发布周期从每 6 个月一个调整为每 12 个月一个。有读者担心：这是不是意味着 Angular 变慢了？
恰恰相反。本文聊聊这次调整背后的逻辑，以及它为什么对使用 Angular 的团队是件好事。
变了什么？
根据 Angular 官方的版本与发布策略，调整前后的对比如下：
| 对比项 | 调整前（v22 之前） | 调整后（v22 起） |
|---|---|---|
| 主版本周期 | 每 6 个月 | 每 12 个月 |
| 每个主版本的 minor 版本 | 1-3 个 | 4-6 个 |
| patch / 预发布 | 约每周 | 约每周（不变） |
| 支持期 | 24 个月 | 24 个月（不变） |
为什么说这是一件好事？
1. 升级成本直接减半
此前一年两次主版本升级，意味着团队每年要做两轮回归测试、两轮依赖适配。改为一年一次后，升级的频率减半，而由于支持期仍是 24 个月，你拥有更充裕的窗口来规划升级，不必”刚升完 vN，就要准备 vN+1″。
2. 废弃周期实际更长了
Angular 的废弃策略是：API 标记为 deprecated 后，至少保留一个完整主版本才可能移除。主版本周期从 6 个月延长到 12 个月，等于把废弃 API 的最短存续期从约 6 个月拉长到约 12 个月——第三方库作者和企业项目都有了更充足的迁移时间。
3. 新功能并没有变慢
这是最容易被误解的一点：主版本变慢 ≠ 功能变慢。每个主版本现在配套 4-6 个 minor 版本（此前仅 1-3 个），新特性会以更高的频率通过 minor 版本持续交付。Signals 的逐步稳定、新控制流语法等能力，当年正是通过这样的迭代节奏落地的。你依然可以几乎每个季度都拿到新能力，只是”破坏性变更”的大门一年才开一次。
4. 对大型团队尤其友好
对多人协作、发布流程严格的企业项目来说，一次主版本升级往往牵动测试、安全审计、CI 调整等多个环节。发布节奏更平缓，意味着升级可以安排进常规迭代计划，而不是变成一年两次的”专项战役”。这与 Angular 面向大型应用的定位是一致的。
总结
一年一个主版本，表面上是”变慢”，实质上是把变化分成了两类：高频且无破坏性的功能迭代（minor + patch，约每周到每季度），和低频且可预期的破坏性变更（major，一年一次）。前者保证开发体验持续进步，后者给团队留出充足的消化时间。
对把 Angular 用在核心业务上的团队来说，这正是一个成熟框架该有的样子：跑得快，更要走得更稳。
