写了三十三篇 Angular 的好话，本篇换个方向：Angular 不擅长什么。技术选型里”知道边界”比”知道优点”更值钱——优点会写在 README 第一行，边界要踩过坑才知道。以下讨论基于 v22 时点的公开事实与工程共识，涉及的数字尽量给量级而非精确值，因为包体积随版本与组件组合浮动。
包体积：框架基线的代价
Angular 是”全家桶”框架：DI、Router、Forms、HttpClient、编译器运行时协作构成完整应用框架。这带来了首屏体积的基线成本——即便是最小化的 v22 应用，其框架部分也明显大于以”渐进增强”为卖点的轻量方案。同等复杂度的待办应用，Svelte 或 Vue 的产物在基线体积上通常更小，这是架构取舍而非工程失误。
Angular 为此提供的缓解手段（都已在前面篇章展开）：
- 路由级代码分割：lazy load 每个 feature route，主包只含首屏（第 24 篇）
@defer懒渲染：视口外组件不进首屏渲染路径（第 8 篇）injectAsync()懒依赖：重组件、重库按需下载（第 19 篇）- standalone + tree-shaking：未引用的指令、管道不进 bundle（第 28 篇）
- Material 按需导入：v17 起组件独立导入，用多少打包多少（第 36 篇）
做完这些，Angular 应用的体积通常能达到业务可接受的水平；但”基线就是比别人重”这一条不会消失。对极致追求首屏字节数的场景（营销页、落地页），静态优先的方案（如 Astro 输出零 JS 或少量孤岛）是更合适的选择。
量化你的体积
判断”重不重”要靠数据而不是印象：
# 构建并输出统计（budgets 预算同时是 CI 闸门）
ng build --stats-json
npx source-map-explorer dist/**/*.jsangular.json 里的 budgets 配置把体积约束固化进构建——初始包与懒加载块各设 warning 与 error 阈值，超标直接构建失败，这比 code review 里口头提醒可靠得多。定预算时参考竞品的真实产物而不是官方 Hello World，后者永远是最优情形。
学习曲线：概念数量是实打实的
一个 Angular 开发者需要同时掌握：TS 严格模式、DI 与注入器层级、模板语法与管道、信号与变更检测模型、Router 全家桶、表单体系、RxJS 至少基础、CLI 与构建配置。v22 用 signals 弱化了 RxJS 依赖、用新 style guide 收敛了细则，但概念总量仍显著高于”一个函数就是组件”的极简框架。
| 人群 | 学习成本判断 |
|---|---|
| 后端出身（尤其 Java/C#） | 低：DI、分层、装饰器是熟悉的世界观 |
| 从 React/Vue 迁移 | 中高：要接受”框架接管结构”的约定 |
| 前端新手 | 高：TS + DI + 模板语法同时上桌 |
| 团队整体 | 低：强约定让新人读规范即可产出一致代码 |
注意最后一条：Angular 的学习曲线在”团队规模”维度上是优势——个人上手慢，但产出的代码高度一致、可替换性强。曲线是个人成本，约定是组织收益。
动态性场景：运行时模板的大门是关着的
Angular 是 AOT-first 的框架：模板在构建期编译成高效的指令函数，运行时不包含通用模板编译器。这带来性能，也带来边界——你无法在运行时编译一段来自服务端的模板字符串：
// 这类需求在 Angular 里没有官方路径
const templateFromServer = apiResponse.templateHtml;
// 不存在 createComponentFromTemplateString 这样的 API典型受影响场景：CMS 让运营拖拽生成页面并输出自定义模板、需要终端用户写模板的报表系统、插件系统允许第三方提交模板源码。
可行的替代方案各有残缺：
| 方案 | 思路 | 残缺 |
|---|---|---|
| 组件白名单 + 动态挂载 | 服务端输出结构化 JSON，映射到预注册组件（第 15 篇） | 模板必须”组件化预判”，无法表达任意结构 |
| 引入运行时模板库 | 第三方方案在运行时模拟编译 | 体积、安全（XSS 面）、与官方机制脱节，升级易碎 |
| iframe 内嵌渲染 | 把动态内容隔离渲染 | 样式与通信割裂 |
对比之下，Vue 允许运行时编译器（显式引入 vue/dist/vue.esm-bundler.js），一些轻量方案天然支持。如果你的产品核心就是”用户定义界面”，这条边界是硬伤。
SSR 边界：强在 hydration，弱在纯静态
v22 的 SSR 故事（hydration、incremental hydration、请求转移）服务的是”应用型站点的首屏体验”，不是”内容型站点”:
- 不是静态站点生成器。Angular 有 SSG 能力，但产物仍是”应用壳 + 激活”，做纯内容站时输出体积与复杂度远超 Astro 类方案
- 浏览器 API 边界。服务端没有
window/localStorage，直接调用会炸掉渲染——isPlatformBrowser守卫是每个 SSR 项目的必修课；第三方库若不 SSR 友好，只能包进ngSkipHydration或客户端-only 的@defer - 长连接与实时场景。WebSocket、WebRTC 这类会话级能力在 SSR 模型里没有位置，必须整体落到浏览器侧
一句话：SSR 在 Angular 里是”增强”，不是”主场”。
移动生态位：Angular 不在场
这是最无争议的边界：
| 方案 | 渲染目标 | 生态成熟度 |
|---|---|---|
| React Native | 原生控件桥接 | 主流选择，社区庞大 |
| Flutter | 自绘引擎 | Google 主推，性能与一致性见长 |
| Ionic + Angular | WebView + 原生壳 | 可用，但本质是网页套壳 |
Angular 没有官方的原生渲染层。用 Angular 做移动端，现实路径是 Ionic——组件体系完整（基于 Web Components 与 Material 风格），但 WebView 渲染的性能上限与原生方案有客观差距：重动画、长列表快速滚动、与系统控件深度集成的场景体验明显落后。同一个团队若既要 Web 又要原生移动端，React 的组件模型可以部分复用到 React Native；Angular 的组件体系则完全留在浏览器里。
生态位与招聘的现实
- 招聘池：Angular 的市场份额在特定区域（企业级、欧洲、金融保险）很强，但在初创与社区声量上不如 React。某些城市招 Angular 前端的选择面更窄，反之 Angular 岗位竞争也小
- 第三方库：React 生态的”什么都有三个版本”在 Angular 里是”官方都有一个”，企业组件（表格、表单、布局）质量高，但新颖的 UI 实验性库通常先出现在 React
- 内容社区：教程与 Stack Overflow 答案总量少于 React，且 Angular 版本演进快，搜索到的旧答案（v8 时代）常常有毒
版本节奏：双刃剑
Angular 每年两个 major、每个版本六个月支持窗口的节奏（上一节时间线可证），对使用方是持续的机会与压力：
- 升级是常态而非例外。想留在受支持版本上，团队每年至少要投入一到两个升级周期。有测试覆盖与 CI 基线的团队，
ng update加迁移工具能把成本压到天级；没有的团队，两年不升就会面临”依赖不兼容 + 安全窗口关闭”的双重挤压 - 第三方库跟随有延迟。组件库、构建插件需要时间适配新 major，激进升级的团队常要给关键依赖”等一个版本”。选型时评估生态里每个关键库的维护活跃度，与评估框架本身同样重要
- 弃用清理是定期任务。Angular 的弃用周期（标记 → 移除）相对友好，但意味着代码库若长期不动，积压的弃用 API 会让下一次升级的成本陡增
对比”稳定压倒一切”的框架哲学，Angular 选择了”可升级性优先”——它不是不破坏兼容，而是保证每次破坏都有自动化迁移兜底。认同这个契约的团队如鱼得水，不认同的团队每个版本都会痛苦。
一张边界地图
把本篇的讨论收拢成决策视角的全景：
| 维度 | Angular 的位置 | 对手更强的地方 |
|---|---|---|
| 首屏体积基线 | 中等偏重 | Svelte/Vue/Astro |
| 学习曲线 | 陡但约定强 | 任何”只学一个 API”的方案 |
| 运行时动态模板 | 硬边界（AOT-only） | Vue 运行时编译 |
| 纯内容站/SSG | 有能力但不擅长 | Astro |
| 原生移动端 | 缺席 | React Native / Flutter |
| 小程序 | 缺席 | Taro / uni-app |
| 企业中后台/表单密集 | 强项 | - |
| 大团队协作一致性 | 强项 | - |
| 官方全家桶完整度 | 强项 | React（需自行拼装） |
何时不应选 Angular
| 场景 | 更合适的选择 | 原因 |
|---|---|---|
| 营销页 / 内容站 / 博客 | Astro、Next.js 静态导出 | 零/少 JS 首屏，体积基线决定胜负 |
| 运行时动态模板为核心的产品 | Vue（运行时编译）或自研方案 | Angular AOT-only 是硬边界 |
| 原生移动 App 为主要目标 | React Native / Flutter | Angular 无原生渲染路径 |
| 微信小程序为主要目标 | 原生小程序框架或 Taro/uni-app 体系 | Angular 编译目标不含小程序 |
| 一两个人的短周期原型 | Svelte / Vue | 概念负担与开发速度 |
| 团队是深度 React 背景且无企业诉求 | React | 迁移成本高于框架差异收益 |
何时应选 Angular
公平起见，反方向的清单：长期维护的企业中后台、团队规模在五人以上且流动可预期、需要强结构与强约定、表单密集、Angular Material 契合设计需求、后端是 Java/.NET 且组织偏好”框架治理”——这些条件下 Angular 的边界恰好都不在关键路径上，而它的强项（全家族 API 一致性、大版本可升级性、官方工具链完整度）会被放大。
选型不是信仰，是约束条件的匹配。认清边界之后，下一篇把前面三十四篇的能力串起来，完整做一个 v22 的 CRUD 应用——那里你会看到 Angular 强项的全貌。