Angular 是由 Google 专职团队维护的开源 Web 应用框架，以 MIT 许可发布，通过 npm 安装而不是购买。angular.dev 是它的官方文档站点。
Angular 框架有明确主张，而不是一个库。路由、表单、依赖注入、HTTP、国际化、测试与构建工具链都作为第一方组件提供，并统一版本推进。这就是框架要求你做的交换：在「每个位置用哪个库」上少一些选择自由，换来这些位置被一致地填满并同步升级。
开发过程是公开的。每一个 PR 与提交都能在 GitHub 上查到，团队在那里分诊 issue，较大的变更在落地前会走公开的 RFC。当前主线是 2026 年 6 月发布的 v22。
Angular Signals 是框架的响应式原语，是一种配合编译期优化的细粒度模型，而不是对整棵组件树做变更检测扫描。这是框架几个版本以来一直推进的主轴，v22 把 Signal Forms、Angular Aria 与异步反应式 API 推进到生产可用状态，完成了这次转向。
服务端渲染与静态站点生成都受支持，并配有完整的 DOM 水合，因此应用可以先以预渲染标记交付，再在客户端接管，而不必丢弃并重建 DOM。
Angular CLI 以 @angular/cli 包发布在 npm 上，提供名为 ng 的可执行文件，脚手架、开发、测试、部署与维护都在同一处完成。底层的构建管线建立在 Vite 与 esbuild 之上。
在项目的整个生命周期里，有两项 CLI 能力比其余更重要：
Angular DevTools 与浏览器自带的开发者工具并列，补上组件树查看器、依赖注入树视图与自定义性能剖析火焰图。测试一侧，Vitest 在稳定发布后成为主要测试运行器，从 Karma 迁移的工具正在推向稳定。
HTML 消毒与 trusted type 支持是内置的，针对跨站脚本与跨站请求伪造。国际化覆盖消息翻译与格式化，包含 Unicode ICU 语法。这两项都属于框架吸收掉的关注点——否则它们会变成每个项目各自的选库决定。
官方给出的入口不是从本地工具链开始的：交互式 StackBlitz 环境意味着在你想要之前不需要任何本地配置。对于评估框架的约定是否适合团队，这把 Node 版本问题从决策的第一个小时里挪走了。
Angular 版本支持是有时限而非无限的，因此升级是一项排期工作而不是可选项。实际顺序是：对 CLI 与核心包一起跑 ng update，让处理常规破坏性变更的自动化代码变换做掉机械部分，再把评审时间留给那些没有迁移脚本的变更。v22 这条线的迁移命令是 ng update @angular/cli@^22 @angular/core@^22。
一次升级有多痛由两件事决定。其一，你的项目是否还落在受支持的版本上——跨越好几个已停止支持的大版本，意味着要按顺序逐个跑迁移而不是一步到位。其二，你是否依赖了已进入弃用窗口的 API，因为它们会在某个大版本边界上被移除。
官方给出三条路径，按模型调用应该发生在哪里来选而不是按偏好来选：服务端逻辑用 Genkit，客户端调用用 Firebase AI Logic，或直接调用 Gemini API。Genkit 需要受支持的服务端环境，例如基于 Node 的服务器，实践中这意味着一个带 SSR 的全栈 Angular 应用，而不是纯客户端构建。
三条路径共有的安全规则毫不含糊：绝不要把 API 密钥放进会随客户端下发的文件，例如 environments.ts。纯客户端应用应把模型调用经 Firebase AI Logic 或你自己控制的代理转发；服务端连接应从密钥管理器或环境变量读取凭据。
Angular 适合宁愿继承决定、也不愿自己做决定的团队。框架给出路由模型、表单模型、DI 容器与构建管线，并期望你使用它们。对规模大或人员流动的团队来说，这种一致性正是价值所在；对两个人的项目来说，它可能读起来像一套繁文缛节。
以下情况适配良好：
以下情况适配不佳：
Angular 面向的是 Web 平台，其覆盖范围由两张公开的矩阵界定，而不是靠一句笼统的兼容性声明。
浏览器支持依照 Baseline 的 widely available 集合来定义，而不是靠一份手工维护的版本清单。每个大版本，团队会挑一个接近发布日的 Baseline 日期，支持 Chrome、Edge、Firefox 与 Safari 上在选定日期前 30 个月内发布的浏览器，目标覆盖约 95% 的网页用户。v22 的 Baseline 日期是 2026-05-07。
工具链矩阵更严格，值得在升级之前而不是升级过程中核对。v22 把 TypeScript 钉在 6.0 线上，接受 Node 22.22.3、24.15.0 或 26.0.0，而 v21 落在 TypeScript 5.9 线。在同一个项目内，@angular/core 与 CLI 的版本必须一致，因为自 v7 起两者共用大版本号。
预发布线的文档单独发布在 next.angular.dev 上，因此评估一个尚未发布的特性不必读着稳定版文档去猜哪里变了。
这里没有价目表、没有席位数、也没有付费档位：框架以 MIT 许可发布，所有包都从公开的 npm registry 安装。仓库许可文件上的版权声明写作 2010-2026 Google LLC，@angular/core 的 npm 元数据同样标注 MIT，当前发布版本为 22.1.5。
这份许可允许的范围很宽。MIT 允许商业使用、修改、分发与私有使用，条件仅限于保留版权与许可声明；软件不附带任何担保。落到实处就是：没有按开发者计的费用、没有用量计量，交付一个基于它构建的产品之前也没有商业许可需要谈判。
真正留下的成本不是许可而是维护。由于大版本按公开时间表离开支持期，真实的预算科目是年度升级的工程时间，加上构建与测试套件消耗的 CI 资源。评估总成本的团队应该给这个节奏定价，而不是假设零成本的许可等于零成本的依赖。
每个大版本的支持期通常为 24 个月，拆成 12 个月的常规更新与 12 个月的长期支持，后者只承载关键修复与安全补丁。这是一条硬边界而非指导意见：在撰写时，从 v2 到 v19 全部已经完全脱离支持，只剩 v22 处于常规支持，v21 与 v20 处于 LTS。
LTS 阶段比「仍受支持」这个说法所暗示的要窄。只有两类问题会被受理：新发现的安全漏洞，或自 LTS 开始之后由第三方变更（例如新浏览器版本）引发的回归。在 LTS 期间发现的普通缺陷不在范围内。
弃用走的是自己的时钟。一个被弃用的 API 至少会活过再一个大版本，也就是不少于 12 个月，之后才成为在大版本边界上被移除的候选——而在这个窗口内，它按 LTS 规则维护，因此即使整个发行版仍处于常规支持，它也只收到关键与安全修复。
v22 展示了这类工作的形状。关于这次发布的独立报道指出，Webpack 支持——包括较旧的 build-angular 与 ngtools 包——已被弃用，该发行版要求 TypeScript 6 并放弃 Node 20，另有两项需要人工处理，因为没有提供迁移脚本。影响面最广的变更是行为层面而非结构层面：OnPush 成为组件的默认变更检测策略，原先的默认策略更名为 Eager，schematics 会通过显式标注既有组件来兜底。
向后兼容性是被验证的，但不是绝对的。变更会经过单元与集成测试、公开 API 类型定义的差异比对，以及 Google 自家依赖应用的测试套件——然而政策仍然保留：在关键安全补丁等例外情形下，修复可能引入向后不兼容的变更。
还有两条较小的边界值得直说。Polyfill 有一条写明的天花板：它无法把老旧缓慢的浏览器变成现代快速的浏览器，而且建议的集合只覆盖运行完整 Angular 应用所需，超出这个集合的特性可能还要再补。官方政策页把完整节奏写成：大约每 12 个月一个大版本，每个大版本配 4 到 6 个小版本，补丁与预发布构建几乎每周一次。目前公开来源在大版本间隔本身上并不一致——一方描述的是 12 个月的周期，另一方仍在描述 6 个月的周期——官方政策页同时注明较长的周期是从 v22 才开始的。任何要做多年升级预算的人，都应该以政策页而不是二手报道来确认当前节奏。
可以。框架以 MIT 许可发布，所有包都从公开的 npm registry 安装，该许可允许商业使用、修改与分发，条件是保留版权与许可声明。软件不附带任何担保。
一个典型大版本总共 24 个月：12 个月的常规更新加 12 个月的长期支持，后者只承载关键修复与安全补丁。此后该版本完全离开支持范围。
v22 处于常规支持，v21 与 v20 处于 LTS。从 v2 到 v19 全部已经完全脱离支持。
v22 把 TypeScript 钉在 6.0 线上，接受 Node 22.22.3、24.15.0 或 26.0.0。版本矩阵按发行版逐一公布，值得在开始升级之前而不是升级途中核对。
CLI 承担了其中大部分：ng update 会运行自动化代码变换来处理常规的破坏性变更。它覆盖不了的是没有迁移脚本的行为变更——在 v22 里，这包括一项没有提供迁移的路由默认值，以及 Webpack 支持的弃用。
支持依照 Baseline 的 widely available 定义：Chrome、Edge、Firefox 与 Safari 上在选定日期前 30 个月内发布的浏览器，目标覆盖约 95% 的网页用户。每个大版本各自挑选接近发布日的 Baseline 日期。
评估阶段可以。交互式 StackBlitz 环境意味着在你想要之前不需要任何本地配置，这也是官方浏览器内教程的入口。
按调用应该发生在哪里来选路径——服务端逻辑用 Genkit，客户端调用用 Firebase AI Logic，或直接调用 Gemini API——并遵守凭据规则：绝不要把 API 密钥放进会随客户端下发的文件，例如 environments.ts。
