Angular 20+ 高阶教程 – 初识 Angular

Before Starting

深入学习 Angular 是一件非常耗时耗力的事情。

实施 Angular 到项目中同样也是一件非常耗时耗力的事情。

在我们做出这么大的投入之前，我们有必要先思考以下几个问题：

什么样的项目适合使用 Angular 做开发？
要深入学习 Angular，需要做哪些学前准备？
Angular 还火吗，Google 会不会突然宣布不再更新？

什么样的项目适合使用 Angular 做开发？

这题是有官方答案的，Angular 团队的 Emma 在 YouTube 介绍过 3 种不同级别的 Angular 项目。

Solo Project – I Miss My Cafe
Team Project – Coffee Table Talks
Big Team Project – ClickUp

她是以团队大小来分级。我们来挨个解读一下

Solo Project（单人项目）

单人项目也意味着项目小、逻辑简单、代码量少、成长慢。毕竟一个人嘛，输出有限。

同时它还有这些特色：

代码风格随意
代码扩展性差
没写测试

之所以会有这些情况，倒不是因为开发者能力差，更多是因为项目不值得投入那么多。

所以，我觉得一个适合单人项目的框架应该具备以下这些特色：

学习成本低
代码量少
容错率高

显然，Angular 一点都不符合这些特性，单单一个 TypeScript 就同时增加了学习成本和代码量，更不用说还有其它的像 RxJS、依赖注入、Web Components 等等复杂概念。

虽然 Angular 团队在 v14 版本后一直努力的降低 Angular 的学习成本和代码量，但我个人觉得这些努力对于单人项目而言，都只是杯水车薪而已。

Team Project（团队项目）

团队项目和单人项目差距太大了。

团队项目意味着项目不小、逻辑不简单、代码量不少，成长速度不慢。不然也不需要这么多人嘛。

人多意味着要分工，分工意味着要协作，那代码就得规范，风格就得统一。

人员流动也是一个需要考虑的问题。单人项目，开发者走了项目往往也垮了。

团队可不一样，一个走了，你得再找一个补上。招人的难度，新人上手的速度，这些都是需要考量的。

项目成长速度快，意味着代码需要具备可维护性，可扩展性，最好还配上一个自动化测试，不然每一次新增需求，修改代码后，牵一发动全身，bug 盛出不穷，谁还敢改呢？

综合上述这些情况，我觉得一个适合团队项目的框架应该具备以下这些特色：

代码规范，统一风格。

不仅仅是团队内的风格，还必须符合市场风格，因为需要考虑到人员流动。
市场通用性。

一个冷门的框架，会加大招人的难度，同时也会提高对旧人的依赖度。这两点都不利于项目发展。
框架的更新与稳定性。

项目在成长，框架自然也必须跟着成长。但如果每一次框架迭代更新都产生 breaking change，那将会给项目带来许多额外的开发成本，所以框架的更新与稳定性也需要被考量。

Angular 在代码规范，统一风格这一点上，做的非常好，无可挑剔。

Angular 不算是通用框架，有些类型的项目偏爱 Angular，比如管理系统，绝对热门。有些类型则完全排除 Angular，比如企业网站，绝对冷门。

Angular 处理 breaking change，migration 都做的很不错，虽然也会有 breanking change，但迁移文档清晰，再加上有辅助工具，这些都大大的降低了项目升级的成本。

Angular 迭代更新的速度不快，在 v14 以前，好几年才会推出一些不完整的小功能。幸好，v14 版本以后，哇！我只能用突飞猛进来形容。

综上，我觉得 Angular 是适用于团队项目的。但是！React 和 Vue 未必就输给 Angular。别忘了，Angular 有着高额的学习成本，另外，Angular 的市场通用性也没有比 React 和 Vue 高。

Big Team Project（大团队项目）

团队项目和大团队项目并没有本质上的区别，它只是量增加了而已，所以不会有新元素需要我们考量。

如果一个团队项目适合使用 Angular，那随着它越长越大，Angular 的优点只会越来越大。

Angular versioning (版本控制)

上一 part 有提到 Angular 的 breaking change 和 migration 都做的不错，这里稍微展开多讲一些关于 Angular 的版本控制。

大中小版本号

Angular 的版本号格式是 1.0.0

每一个星期会推出一个小版本，比如 1.0.1

这个小版本不会有任何 breaking change 也不会有任何新功能，它只用于修复 bug 而已，也就是说，我们总是可以安心升级小版本。

每一两个月，Angular 会推出一个中版本，比如 1.1.0

这个中版本会推出新功能，但同时会确保没有 breaking change，所以我们也可以安心升级。

每半年，Angular 会推出一个大版本，比如 2.0.0

这个版本会有新功能，同时也可能伴随 breaking change，我们要升级的话，需要按照 migration 的指示调整 breaking change 影响到的代码。

Long Term Support (LTS)

任何一个 Angular 版本都有维护期限。

如果大版本号是奇数 (e.g. v15, v17, v19) 那它的期限是半年。

也就是说，在发布后的半年内，如果出现 bug，那 Angular 团队会修复，但过了这半年，即使发现 bug 也不会再去修复了。

举例

2025-01-01 推出 v15.0.0

2025-01-02 推出 v15.0.1 修复 bug

2025-02-01 推出 v15.1.0 加新功能

2025-02-01 推出 v15.1.1 修复 bug

2025-07-01 推出 v16.0.0

2025-07-02 发现 v15.1.1 和 v16.0.0 有一个相同的 bug。此时距离 v15 发布已经超过半年了，所以 v15 不会再得到 bug 修复，只有 v16 会修复 bug。

2025-07-02 推出 v16.0.1 修复 bug

另外，如果大版本号是偶数 (e.g. v16, v18, v19) 那它的寿命则是一年。

举例

2025-01-01 推出 v16.0.0

2025-01-02 推出 v16.0.1 修复 bug

2025-02-01 推出 v16.1.0 加新功能

2025-02-01 推出 v16.1.1 修复 bug

2025-07-01 推出 v17.0.0

2025-07-02 发现 v16.1.1 和 v17.0.0 有一个相同的 bug。此时距离 v16 还未满一年，所以 v16 和 v17 都会得到 bug 修复。

2025-07-02 推出 v16.1.2 修复 bug 同时也会推出 v17.0.1 修复相同的 bug

结论：总是使用最新的版本是 best practices，但如果你无法跟上这个节奏，那可以考量慢一拍，只使用偶数的大版本号。

新功能 / 新语法の RFC > preview > stable > migration > deprecated > removed

Angular 大型新功能的发布周期是非常长的，往往会横跨好几个版本，耗时数年才会完备。

这里举一个例子 – Signal 功能 (注：这里 Signal 是一个统称，往细讲，它是由一系列小功能组成的)

RFC

第一步是推出 RFC (Request for Comments)

2023-04-04 推出了 RFC，目的是开放讨论，聆听意见。

Preview

第二步是推出 preview 版本

preview 就是预览版，抢鲜体验，此时功能尚未完备，处于非常不稳定阶段。

我们使用它，随时有可能出现 bug 和 breaking change。

注：严格来讲不叫 breaking change，因为 preview 阶段 Angular 团队可以任意修改 API，功能设计等等，完全无责去提供 migration 文档。

所以假如我们要抢先体验，就要确保有能力自行承担其风险。

Stable

第三步是 stable

图片来源 – Can I use Angular

蓝色是 preview，绿色是 stable。

大部分 Signal 功能在 v19 或 v20 进入 stable 版。

从 v16 的 preview 到 v20 的 stable，横跨 4 个版本，耗时两年，够久吧...

Migration tools

新功能/语法的诞生，必然是为了取代旧的实现方式，要想从旧 > 新，我们就需要修改现有代码。

如果要修改的代码很多，这就会让我们失去使用新功能/语法的动力。

Google 内部有很多项目都使用 Angular，为了让大家有动力使用新功能/语法，Angular 团队会尽力推出 migration tool 帮助大家批量修改代码。

比如说，只要输入这句 command

ng generate @angular/core:signal-queries-migration

代码就会从

变成

Deprecated

随着越来越多人 migration to 新功能/语法，旧的功能就会进入 deprecated 状态。

deprecated 的意思是，这个旧功能，迟早有一天会被彻底的删除，我们不应该再去使用它了，并且应尽早把它 migrate 掉。

当然也不是所有被替代掉的旧功能都会被 deprecate，不一定的，有一些旧功能会因为 Google 内部不愿意 migrate 而一直被保留着，甚至被 un-deprecated (复活)。

Removed

当 Google 内部没有在依赖一个旧功能时，Angular 团队就会正式把这个旧功能彻底删除掉。

小结

RFC > preview > stable > migration > deprecated > removed

从这个流程可以看出，Angular 团队推动新功能/语法是按部就班慢慢来的，虽然慢，但稳，而且给了使用者很宽裕的时间去做适应和调整，这点非常棒👍。

如何适应 Angular Versioning？

两个重点

always latest version。

中小版本直接升，因为没有 breaking change 问题。

大版本每半年升一次，虽然会有 breadking change，但通常不会多，照着 migration guide 微调就 ok 了。

如果影响范围很广，通常 Angular 团队会搭配 migration tool 来帮助升级，所以我们真的不用太担心会跟不上。
don‘t use preview

不要用 preview 功能，总是等新功能/语法 stable 并且有 migration tools 以后才 migrate to 新功能/语法。

虽然 preview 的 breaking change 未必很多，但往往那些 breaking change 很要命，所以最好还是别用。

另外，特别讲一下，上面这两点适合绝大部分的人，但如果你和我一样是 Angular 重度使用者，那就另当别论。

如果你是 Angular 重度使用者 (重度的意思是你已经用到走火入魔，extend > override > hacking 全都都用上了)，

那我建议你踊跃参与 RFC 讨论，并且趁早使用 preview 版，并对它指指点点。为什么要这样呢？

因为 Angular 团队远没有你想象中的厉害，他们对 Angular 在真实项目中遇到的难题，通常是不清楚的。

你不讲，他们就会乱设计一通，然后你就需要在项目中 extend > override > hacking 🙄。

学习 Angular 的预备条件

坊间有许多谣言说 Angular 的学习门槛高、曲线陡峭、概念多、复杂等等。

我想说...其实这些都是真的。

Angular 团队是一群不爱创新，爱 follow 标准，爱小题大做的一群人。（了解这群人的特性，对理解 Angular 很有帮助）

任何一个问题的解决方案，你都可以看见它背后的深(小)谋(题)远(大)虑(做)...看见它出自于某某远古伟大的概念...依据了某某远古伟大的标准...

那它为什么要这么搞呢? 其实很简单，因为要稳定，你不深谋远虑怎么避免 breaking change 呢？你不 follow 远古概念，怎么知道新概念可以活下去呢（至少远古的活了下来）？你没有标准，出事情的时候要怎样补救呢。

所以这些都是使用 Angular 的代价和成本。

举个例子，Angular 的 Component 对标的是 W3C 的 Web Component。

Angular Form 对标原生 HTML Form。

它们的概念和玩法高度相似。你甚至可以认为 Angular 就是 Web Component 和 HTML Form 的优化和扩展版本，骨子里都是一个东西，一个思路。

所以呢，要学好 Angular，首先需要找到它对标参照的概念和方法去学习，比如 Web Component、Form、Dependency Inject、HttpClient 等等。然后在那些基础上再学习 Angular 扩展出的特性，这样才能学好 Angular。

本系列教程也会依据这个方式去教。

更新：2020 - 2022 年 Angular 团队换了一大批人，这群人多了一个重要得特性 -- 愿意聆听。

再补充一点，TypeScript 和 RxJS 也是学习 Angular 的必备技能 (不需要到精通，但至少要熟练)，如果大家对它们不熟悉的话，建议先阅读下面这几篇文章：

Angular 还火吗? 会不会被 Google 砍掉?

传说 Google 有一个关门部，专门杀掉 Google 的项目，距今已经杀掉了 293 个项目。 AngularJS (Angular 的前生) 就是其中一个。

上面提到 Angular 的学习成本很高，如果哪天 Google 突然把它砍了，那不是白学了吗?

担心是对的，但也不用过分担心。就目前的局势来看。 Google 并没有计划杀掉 Angular。甚至可以说 Angular 最糟糕的时代已经过去了。目前算是欣欣向荣的。

至于 Angular 会火起来吗? 这是不可能的。因为 Angular 的定位和思想已经注定了它不会大受欢迎。就类似 React 的 Redux 一样。它的 time travel 非常厉害，但是绝大部分项目是不需要的。

当年之所以会火，只是因为 React 还没有推出 Hook 而已。 Angular 曾经也火过，但那也只是因为 Vue 还不完善而已。

总结：不火，而且越来越凉。但短期内 (3-5年) 完全看不出一丁点被砍掉的迹象。

聊聊那些年 Angular 的坎坷路

1. 跨时代的设计

AngularJS 1.0 是在 2009 发布的。开始的定位是帮助设计师快速搭建原型。但其 MVVM 的思想也收到了前端开发者的喜爱。

于是就开始走偏了。

巅峰时期 Angular 1.2 是在 2014 年。当时同类产品有 knockoutjs，Embed.js，Backbone.js，还有司徒正美的 Avalon。

AngularJS 无疑是里面最优秀的，但它依然存在太多太多的问题。

试想想大中小项目统统都用 AngularJS，而它一开始的定位又不是这些，怎么可能会做得好呢。

后来 Google Ads 团队看上了 AngularJS，这是一件好事，也是一件坏事。

好的方面是 Google 会给予 Angular 资源 (钱)，坏的方面是 Angular 会被 Google 牢牢控制。

比如说，Google Ads 团队要求使用静态语言，所以 Angular 2 一推出的时候，它支持 3 种语言：TypeScript，JavaScript 和 Dart。

当时 TypeScript 是 version 1.8，根本没有人在用，Dart 更是只有 Google 一家公司在用，而 JavaScript 也只短暂的支持一个版本而已，Angular v4 直接就不支持 JavaScript 了。

除了语言，bundler 也是当时一个超前设计，那使用用的是 SystemJS，连 Webpack 都还没出现。

也因为这种超前设计，导致了 AngularJS 使用者无法直接过渡到 Angular 里。

2. 替代品的崛起

Vue 的渐进式完全满足了迷茫中的 AngularJS 使用者。

React 则开启了另一条康庄大道。

至此 Angular 跨时代设计方案成功掉粉无数，随时可能被关门部盯上...

3. 错误的战略，痛失翻盘希望

随着 TypeScript 和工程化的普及，使用 Angular 的成本得到了大大的降低，Angular 似乎迎来了逆风翻盘的希望。

可惜的是，Angular 团队选择了无视所有支持者的 Feature Request，孤注一掷的去搞 render engine。

以至于在许多年里，Angular 一直没有推出 new Features，bug 也没有 fix。一个 render engine 就搞了 3 年。

粉丝数直接掉到谷底。

4. 内部纷争

2020 年是 Angular 离死亡最接近的一年，参考 No，I don't want to become an Angular GDE

许多核心队员纷纷离开，几乎是换了一次血。

许多粉丝很担心是否 Angular 还会受到 Google 的青睐，还是会让 Flutter 取而代之。

人心惶惶的一年。。。

5. 迎来曙光

庆幸的是，新成员没有辜负前辈们的努力，Angular 默默的翻新了几个版本后，终于在 v14，v15 迎来了稳定的发展。

从 roadmap 我们可以看到 Angular 团队依然再努力着让 Angular 变得更好，而且是按部就班的去做。

稳定持续输出正是我们期望 Angular 做到的。

Angular 的断层问题

下图是 Angular npm last 7 days 的下载数量

你没看错，任然有许多人在使用 5 年前发布的 Angular v9。

Angular 从 v14.0.0 开始有比较大的改动 (因为换了一批人，想法方向不一样了)

这些改动大部分不是增加了新功能，而是修改了语法 (coding styles)。

Angular Team 的动机是想透过修改语法来降低学习成本，比如它们除去了：

Decorator (replaced by Signal & Global Functon)
NgModule (replaced by Standalone Component)
Zone.js (replaced by Signal)
RxJS (replaced by Signal)
指令微语法 (replaced by Control Flow)

动机虽然是好的，但是这类型的改动往往会让开发者形成断层。

也就是说会有一部分人一直停留在旧的版本 (比如 v9.0.0)，有另一部人会使用最新的版本 (v19, v20)。

会出现这种情形也很正常，因为这些改动最大的利益在于降低了学习成本，这只对新人有意义，对旧人来说利益很小甚至是有害的。

断层对 Angular 的伤害是很大的：

向后兼容

保持对旧版本的兼容会大大增加代码设计的难度，代码量，维护，通通增加。
学习资源混乱

Angular 团队自己的教程就很乱，

angular.dev 不完整，angular.io 是旧的，你要看哪一个学习？

你该怎么选？

如果你是一名 Angular 开发者，目前掌握着 v9 的能力，维护者 v9 的项目，你可能会挺纠结的。

你会感觉自己正在被淘汰，但又不知道是否该学新的 Angular 或者干脆转投 Vue，React。

我给你的建议是，先继续看我的教程，如果你感觉吃力，那我建议你改投 Vue，React。

如果你觉得还可以，那看完它以后，尝试用新的 coding styles 去做新项目，或者新功能，一点一点的升级。

Angular 是不是只适合用来做 Control Panel?

Google 内部有 2 套主流的前端框架，一个是 Angular 另一个是 Wiz (闭源)。

Angular 的强项是处理交互复杂的 Web Application，而 Wiz 的强项是快速渲染。

比方说，Google Ads，Cloud 这类 Control Panel 就属于交互复杂的 Web Application，适合用 Angular 开发。

而像 Youtube，Search 这些非常重视快速渲染的 Web Application，则更适合用 Wiz 开发。

这两套框架各有所长，多年来都是各自发展。

也因为这样，Angular 一直都有性能缺陷，要知道 Angular Team 有一个潜规则 -- 只要 Google 内部不需要 (因为要性能，他们会用 Wiz，不会用 Angular)，就绝不提升 Angular。

长久下来，Angular 自然就变得只适合开发 Control Panel 了。

这个现象一直到近两年才有了转变。

这两年，Angular 发力搞了 Signal，SSR Hydration，@defer，NgOptimizedImage，甚至还说以后要整合 Wiz。总之就是要让 Angular “快" 起来。

另一方面，Google 内部也选了 Angular 作为 Gemini 的前端框架，这给了 Angular 一个性能上的重任，要知道 Gemini 可是 Google 用来对抗 ChatGPT 的丫。

所以现在的 Angular 不仅仅适合交互复杂的 Web Application，也可以用来处理需要快速渲染的 Web Application。(注：我说的是 "可以" 而不是 "适合")

优化性能是 Angular 未来一两年的大方向，相信再过两年 Angular 就可以完全胜任了，近期期待。。。🚀

想看看 Angular 用于非 Control Panel 项目的读友们，可以参考这里：https://www.madewithangular.com/sites

兴杰(stooges.com.my)

Angular 20+ 高阶教程 – 初识 Angular

Before Starting