Angular 从 v12 开始每年 5/6 月与 11 月各发一个 major 版本，节奏稳定到可以预测。但 2022 年到 2026 年这四年间，框架内部发生了自 Angular 2 以来最大的一次范式转移：standalone 取代 NgModule、Signals 取代 Zone 驱动的变更检测、新控制流取代结构型指令、Signal Forms 取代 Reactive Forms。本文按时间线盘点 v14 到 v22 的关键变化，帮你建立一张”哪个能力在哪个版本可用”的地图——无论新项目选型还是老项目升级，它都是前置功课。
时间线总览
| 版本 | 发布 | 一句话概括 |
|---|---|---|
| v14 | 2022-06 | 严格模式成为 CLI 默认；Typed Reactive Forms 让表单类型完整；standalone API 以预览形态亮相 |
| v15 | 2022-11 | standalone API 稳定并成为官方推荐；directive composition API；Material 组件基于 MDC 重构 |
| v16 | 2023-05 | Signals 开发者预览；required inputs；esbuild 开发服务器大幅提速 |
| v17 | 2023-11 | 新控制流 @if/@for/@switch 与 @defer 稳定；Signals 转正；SSR hydration 默认可用；Material M3 主题预览 |
| v18 | 2024-05 | zoneless 开发者预览；Material M3 主题稳定；signal inputs、model、signal queries 转正 |
| v19 | 2024-11 | CLI 生成 standalone 默认（不再产出 NgModule）；incremental hydration 预览；linkedSignal、resource 实验性 |
| v20 | 2025-05 | 官方 style guide 整体重写；Vitest 实验性支持；httpResource 实验性亮相；zoneless 迁移 schematic |
| v21 | 2025-11 | zoneless 稳定并成为新应用默认；HttpClient 默认可注入；Signal Forms 开发者预览 |
| v22 | 2026-05 | OnPush 成为默认策略（原 Default 更名 Eager）；Signal Forms 稳定；@Service() 与 injectAsync()；HttpClient 默认 Fetch 后端；TS 6 / Node 22+ |
timeline
title Angular v14 → v22 演进主线
2022 : v14 standalone 预览 : v15 standalone 稳定
2023 : v16 Signals 预览 : v17 新控制流 + Signals 稳定
2024 : v18 zoneless 预览 + M3 稳定 : v19 standalone 成为 CLI 默认
2025 : v20 style guide 重写 : v21 zoneless 稳定默认
2026 : v22 OnPush 默认 + Signal Forms 稳定四条主线贯穿始终，分别对应”代码怎么组织”（standalone）、“状态怎么响应”（Signals）、“检测怎么触发”（zoneless）与”表单怎么写”（Signal Forms）。下文按阶段展开。
前半场：standalone 与 Signals 的孕育（v14–v17）
v14（2022-06） 打下的地基偏工程侧：ng new 默认开启 TS 严格模式，从此模板里的类型错误与 TS 一视同仁；Typed Reactive Forms 补齐了 FormControl<string> 的泛型能力，旧表单代码可以渐进收紧类型。standalone API 在这个版本以预览形态出现——bootstrapApplication、无 NgModule 的组件声明，彼时还需要显式开启兼容标志。
v15（2022-11） 让 standalone 转正：官方文档全面改写为 standalone 优先，bootstrapApplication(AppComponent) 成为标准入口。directive composition API 允许把指令”混入”组件复用行为。Material 完成 MDC 基础重构，DOM 结构与样式体系向即将到来的 M3 靠拢。
v16（2023-05） 是范式转移的起点：signal()、computed()、effect() 以开发者预览发布，“响应式状态容器”第一次成为框架概念。required inputs（input.required<T>() 的前身形态）与 Router 数据绑定到组件输入的能力，让”输入”从装饰器参数变成一等公民。esbuild 开发服务器让冷启动时间大幅下降。
v17（2023-11） 是近四年观感变化最大的一版：新控制流 @if / @for / @switch 直接进入稳定（不再需要 CommonModule），@defer 懒加载块同期亮相；Signals 转正，signal inputs / outputs 等响应式 API 家族成形；SSR hydration 走向默认推荐，provideClientHydration() 一行接入。Material 同期给出 M3 主题预览。
中场：响应式接管一切（v18–v20）
v18（2024-05）：zoneless 以 provideZonelessChangeDetection 形态进入开发者预览——变更检测从”Zone 猜测”转向”信号通知”的战役正式打响。signal inputs、model inputs、signal queries 全部转正，组件的输入输出全面信号化。Material 的 M3（Material Design 3）主题体系稳定，mat.theme 与 design token 成为样式基石（第 36、37 篇展开）。
v19（2024-11）：CLI 默认生成 standalone 代码，app.module.ts 从新项目中消失——standalone 从”推荐”变成”默认”，NgModule 退居兼容场景（第 28 篇）。incremental hydration 预览让 SSR 应用可以按需 hydration。resource() / linkedSignal() 以实验性身份出现，为声明式异步数据铺路。
v20（2025-05）：官方 style guide 整体重写，全面拥抱 signals、inject、新控制流的现代风格（第 31 篇展开）；Vitest 实验性支持为脱离 Karma 做准备；httpResource() 实验性亮相。zoneless 迁移 schematic 提供自动化检查，为下一版的默认化清障。
近两版：v21 与 v22
v21（2025-11）：zoneless 稳定并成为新应用默认——新项目不再引入 zone.js，变更检测完全由信号驱动（第 20、21 篇展开其机制）。HttpClient 默认可注入，provideHttpClient() 只在需要拦截器等定制时才出现。Signal Forms 以开发者预览亮相，form() / [formField] 初步成形。
v22（2026-05） 是本系列的写作基线，收官性质的版本：
- OnPush 成为默认变更检测策略，原来的
Default策略更名为Eager，仅作为显式回退保留 - Signal Forms 稳定（第 25 篇），表单值与状态全面信号化，
FormValueControl取代ControlValueAccessor成为新的自定义控件协议 @Service()装饰器等价于@Injectable({ providedIn: 'root' })且强制inject()注入；injectAsync()把懒加载依赖纳入 DI（第 19 篇）- HttpClient 默认 Fetch 后端，
withFetch()成为默认行为，上传进度等 XHR 特性可显式回退（第 23 篇） - 工具链基线：TypeScript 6、Node 22+、TS 严格模式
四条主线的版本对照
| 能力 | 预览 | 稳定 | 默认 |
|---|---|---|---|
| standalone API | v14 | v15 | v19（CLI 不再生成 NgModule） |
新控制流 @if/@for | v17 前的实验期 | v17 | v17 起官方文档全面采用 |
| Signals | v16 | v17 | v18 起 inputs/queries 全信号化 |
| zoneless | v18 | v21 | v21（新应用） |
| OnPush 默认 | - | - | v22（Default 更名 Eager） |
| Signal Forms | v21 | v22 | 官方推荐新项目采用 |
| resource / httpResource | v19/v20 | v22 | - |
| Material M3 主题 | v17 | v18 | - |
规律很清晰：Angular 的策略是”预览一到两个版本、稳定后再默认化”，跨度通常一年。评估任何”新 API 能不能上生产”时，对着这张表查它处在哪个阶段即可。
迁移策略与工具
升级的官方姿势永远是 ng update，它同时执行依赖升级与自动化代码迁移：
# 逐个大版本升级，不要跳级
ng update @angular/core@15 @angular/cli@15
ng update @angular/core@16 @angular/cli@16
# ... 依次到 22针对特定范式的官方迁移 schematic：
# NgModule → standalone
ng generate @angular/core:standalone
# *ngIf/*ngFor → @if/@for
ng generate @angular/core:control-flow
# 构造器注入 → inject()
ng generate @angular/core:inject
# zoneless 迁移检查（v20+）
ng generate @angular/core:zoneless三点经验：
- 逐版本升级。每个 major 的自动迁移只针对上一个版本的设计，跳级会漏掉中间的 deprecation 处理
- 先升级再重构。
ng update完成后代码仍在旧范式下可运行，standalone、控制流、inject 的迁移可以拆成多个 PR 慢慢做 - Signal Forms 以手工迁移为主。v22 时点官方尚未提供表单的自动化迁移，好在两套表单可以共存（第 25 篇），按页面逐步替换即可
升级前的检查清单
| 检查项 | 命令 / 方法 |
|---|---|
| 依赖兼容性 | 逐个确认第三方库（Material、CDK、组件库）是否已支持目标版本 |
| 测试可运行 | ng test 全绿是自动迁移的安全网 |
| 提交干净的基线 | 升级 PR 只含迁移产物，不混入手工改动 |
| deprecation 报告 | 编译输出中的弃用提示即下一版本的”迁移预告” |
| 构建产物对比 | 升级前后 ng build 产物体积对比，异常膨胀往往意味着 tree-shaking 失效 |
升级后跑一遍 ng build 看弃用警告是免费的未来投资：Angular 的惯例是一个版本标记弃用、之后的 major 移除，警告出现时你有一个完整版本周期去处理。
两条隐性主线：工具链与 Material
除四大主线外，还有两条容易被忽略的演进线索同样贯穿 v14 到 v22：
工具链：v14 的可选 esbuild → v16 的 esbuild 开发服务器 → v17 的 Vite 化 dev server 与 SSR 构建提速 → v20 的 Vitest 实验性支持 → v22 的 Node 22+ 基线。构建体验的改进没有范式转移那么耀眼，但每天都省你的时间。
Angular Material：v15 的 MDC 重构（DOM 与样式体系换底）→ v17 的 M3 主题预览 → v18 的 M3 稳定（mat.theme 与 design token 体系，第 36 篇）→ v22 的全面 token 化与去动画依赖。Material 的每个大版本都与框架主版本同日发布，升级 @angular/core 时记得同步升 Material 与 CDK。
老项目该不该升
| 判断 | 建议动作 |
|---|---|
| v14+ 的活跃项目 | 值得升到 v22：每版本改动都有迁移工具，收益是性能与生态 |
| v13 及更早 | 先评估测试覆盖率，否则升级即重写 |
| 已冻结维护的项目 | 不建议动，Angular 对旧版本的安全支持窗口有限，评估风险 |
| 新项目 | 直接 v22 + zoneless + Signal Forms，没有理由从旧范式起步 |
版本演进也塑造了”何时不应选 Angular”的判断——框架的能力边界与学习成本同样真实，这是下一篇的主题。