Angular性能优化实践 on 雪狼的书斋

1.Angular应用“加速”秘籍：让你的用户不再等待！

Mon, 01 Jan 0001 00:00:00 +0000

想象一下，你的网站是一家餐厅。一位饥肠辘辘的顾客（用户）推门而入。他是会立刻被引导入座、并看到一份精致的菜单（首屏秒开）？还是会在门口站半天，无人问津，最终不耐烦地离去？

性能，就是你这家「线上餐厅」的服务质量和生命线。一个功能再强大、界面再华丽的应用，如果慢如蜗牛，那它在用户眼中，也只是一家体验糟糕的「苍蝇馆子」。

在这个「耐心」比黄金还贵的时代，让用户等待，就等于把用户推给你的竞争对手。作为一名追求卓越的工程师，「快」，应该成为我们刻在骨子里的执念。本章，雪狼将为你献上一整本 Angular 应用的「加速秘籍」，从加载到交互，全方位提升你「餐厅」的「米其林星级」。

性能优化的三大支柱#

要打造极致的性能体验，我们需要从三个维度去系统地思考和优化。这就像支撑一座大厦的三根顶梁柱，缺一不可。

支柱一：加载性能 —— 决定「第一印象」#

这是用户访问你的应用时，最先感受到的性能。它决定了你的「餐厅」门面是否光鲜，迎宾是否迅速。

核心目标：让页面尽快变得可见和可交互。
关键指标：
- FCP (First Contentful Paint)：首次内容绘制。即浏览器首次渲染出任何文本、图片等内容的时间点。这是消除用户「白屏焦虑」的第一个里程碑。
- LCP (Largest Contentful Paint)：最大内容绘制。即视口中最大的图像或文本块完成渲染的时间。它标志着页面的主要内容已对用户可见。
- TTI (Time to Interactive)：可交互时间。即页面已经渲染完成，并能可靠地响应用户输入（如点击）的时间。
核心秘籍（后续章节详解）：
- 代码分割与惰性加载：别在开业时就把所有厨师、服务员、食材全堆在前厅。只加载当前页面必需的资源。
- 打包体积优化：精简你的 JavaScript 包，每一 KB 都弥足珍贵。
- 图片与资源优化：对图片、字体等资源进行压缩和格式转换。
- 服务端渲染 (SSR)：直接给用户一个「预制菜」，而不是让他看着你从和面开始。

支柱二：运行时性能 —— 保证「丝般顺滑」#

当应用加载完成后，用户在其中进行各种操作（滚动、点击、输入）时的体验，就是运行时性能。它决定了你的「餐厅」服务是否「丝般顺滑」。

核心目标：确保应用对用户的操作能立即给出反馈，动画流畅，无卡顿感。
关键指标：
- INP (Interaction to Next Paint)：下一次绘制的交互延迟。这是谷歌新推出的、即将取代 FID 的核心指标，衡量从用户交互到下一次屏幕更新的时间，直接反映应用的响应能力。
- TBT (Total Blocking Time)：总阻塞时间。衡量在 FCP 和 TTI 之间，主线程被长任务阻塞的总时间。
- FPS (Frames Per Second)：每秒帧率。动画或滚动时，低于 60fps 就会让用户感到卡顿。
核心秘籍（后续章节详解）：
- 变更检测策略优化 (OnPush / Signals)：别让你的服务员（变更检测）在餐厅里「无头苍蝇」般乱窜。
- 长列表渲染优化 (@for / 虚拟滚动)：高效地管理你的「大菜单」。

2.Web Vitals与Angular：如何让你的应用在谷歌评分中“C位出道”

Mon, 01 Jan 0001 00:00:00 +0000

在如今这个流量为王的时代，网站的「酒香」，也怕「巷子深」。如何让自己的网站在 Google 搜索结果中脱颖而出，获得更高的排名？除了优质的内容，你还必须通过一场由 Google 主持的、极其严格的「用户体验海选」。

这场「海选」的核心评判标准，就是 核心 Web 指标（Core Web Vitals）。

它们是 Google 用来量化你网站用户体验的三位「铁面评委」。今天，雪狼就化身「金牌导师」，为你深度解读这三位评委的「打分标准」，并传授一套专门针对 Angular 应用的「应试技巧」，助你的应用在这场海选中征服评委，最终「C 位出道」！

认识三位「评委」：LCP, INP, CLS#

1. LCP 评委 (Largest Contentful Paint) - 「视觉呈现」导师#

考核内容：加载性能。它测量的是页面主要内容（通常是最大的图片或文本块）加载完成并显示出来所需的时间。
评委心声：「别让我盯着白屏发呆！我要看干货，越快越好！」
高分标准：低于 2.5 秒。

2. INP 评委 (Interaction to Next Paint) - 「交互响应」导师#

考核内容：响应速度。它测量的是从用户进行交互（点击、输入等）到屏幕上出现下一个视觉反馈的全部时长。它代表了应用的「跟手程度」。（注意：它正在取代旧的 FID 指标）。
评委心声：「我点了你，你倒是给点反应啊！别像个木头人！」
高分标准：低于 200 毫秒。

3. CLS 评委 (Cumulative Layout Shift) - 「舞台稳定」导师#

考核内容：视觉稳定性。它测量的是在加载过程中，页面内容非预期的「跳动」程度。
评委心声：「我正要点那个按钮，『pia』的一下广告弹出来，按钮被挤下去了！这种体验简直是灾难！」
高分标准：低于 0.1。

Angular 的「应试宝典」：逐个击破#

攻略一：冲刺 LCP (加载速度)#

LCP 的瓶颈，通常在于初始加载的 JavaScript 体积过大，或者关键资源（如主图）加载过慢。

3.Angular惰性加载：提升首屏速度的“障眼法”

Mon, 01 Jan 0001 00:00:00 +0000

想象一下，你要登上泰坦尼克号，开始一段豪华的海上旅程。但在登船时，船长却告诉你：「对不起，先生，我们必须等船上所有的货物 —— 包括要运往纽约、伦敦、甚至开罗的 —— 全部装载完毕后，才能启航。」你会作何感想？

听起来很荒谬，但这正是许多 Angular 应用正在做的事情。我们称之为饥饿加载（Eager Loading）。在应用启动时，它会贪婪地、饥饿地将所有模块、所有组件、所有功能，无论用户是否需要，全部打包成一个巨大的 main.js 文件，一次性塞给用户。

结果就是，你的「泰坦尼克号」（应用）变得无比笨重，需要漫长的时间才能「离港」（完成首屏加载）。而在这场与用户耐心的赛跑中，你早已输在了起跑线上。

今天，雪狼就来教你一手绝妙的「障眼法」 —— 惰性加载（Lazy Loading），让你能把「巨轮」伪装成「快艇」，瞬间起航！

什么是惰性加载？ —— 「按需点餐」的智慧#

与「自助餐」式的饥饿加载相反，惰性加载是一种「点单式」的智慧。

饥饿加载：你走进餐厅，还没坐下，餐厅就把菜单上所有的菜（包括你永远不会点的）全给你上了一遍，堆满了你的桌子。
惰性加载：你走进餐厅，服务员只递给你一本菜单（应用的核心外壳）。只有当你点了某道菜（点击了某个功能的链接）时，厨房（服务器）才开始为你现做这道菜（下载该功能的代码包）。

它的核心思想，就是代码分割（Code Splitting）。将庞大的应用，按功能或路由，拆分成一个个独立、小巧的代码块（Chunks），只在需要时才加载它们。

为何惰性加载是性能优化的「第一杀手锏」？#

急剧缩小初始包体积：这是最直接、最显著的好处。更小的 main.js 意味着更快的下载、更快的解析、更快的首屏渲染。你的 LCP、FCP、TTI 指标会得到质的飞跃。
更优的资源利用：浏览器无需在启动时就为用户可能永远不会访问的「管理员后台」或「年度报表」功能，去浪费宝贵的 CPU 和内存。
更高效的缓存：每个功能模块的代码块可以被浏览器独立缓存。当你更新了「用户中心」功能时，用户只需重新下载「用户中心」那一个几十 KB 的小文件，而不是整个几 MB 的应用。

如何施展「障眼法」：从 `loadChildren` 到 `loadComponent`#

在现代 Angular 中，实现惰性加载的「咒语」已经全面升级，变得更加简单直接。

方式一：惰性加载一个独立组件 (`loadComponent`)#

这是最细粒度的惰性加载，当你只需要懒加载一个作为路由入口的组件时使用。

// app.routes.ts
export const routes: Routes = [
  {
    path: 'admin',
    // 当用户访问 /admin 时，才去下载并渲染 AdminComponent
    loadComponent: () => import('./admin/admin.component').then(c => c.AdminComponent)
  }
];

方式二：惰性加载一组路由 (`loadChildren`)#

当你需要为一个完整的功能区（如「产品中心」）惰性加载其下属的所有路由时，可以使用 loadChildren。它不再加载一个 NgModule，而是直接加载一个包含 Routes 数组的文件。

4.变更检测策略：Angular性能优化的“葵花宝典”

Mon, 01 Jan 0001 00:00:00 +0000

在 Angular 性能优化的武林中，流传着百般武艺：惰性加载、@for 中的 track、纯管道……但若论哪一本秘籍的威力最大、最能助你打通「任督二脉」，问鼎性能之巅，那无疑是变更检测策略中的 OnPush。

它，就是 Angular 性能优化领域的「葵花宝典」。

这本宝典，威力无穷，能让你的应用「快如闪电」。但它也并非人人可练，若内功（对数据流的理解）不纯，心法（使用姿势）不当，极易「走火入魔」，陷入更深的困惑。今天，雪狼就为你完整解读这本宝典的奥义。

默认之「咒」：草木皆兵的 `CheckAlways`#

在修炼宝典之前，你需知晓你所要对抗的「心魔」是什么。Angular 的默认变更检测策略 CheckAlways，就是一个「草木皆兵、宁枉勿纵」的偏执狂。

它像一个极度缺乏安全感的将军，帐篷外任何一点风吹草动（任何异步事件），都会让他把全军将士（所有组件）都叫起来，从头到脚盘问一遍。这种策略保证了「万无一失」，但也造成了巨大的、不必要的内耗。当你的「军队」规模庞大时，这种无休止的盘问，就是卡顿和掉帧的根源。

宝典心法：`OnPush` 的「闭关」誓言#

要修炼 OnPush，你首先要在组件的「丹田」处（@Component 装饰器），立下一个「闭关锁国」的誓言：

@Component({
  //...
  changeDetection: ChangeDetectionStrategy.OnPush,
})

这个誓言，是在告诉 Angular：「从此刻起，我（本组件）将与外界的凡俗杂事断绝。除非符合以下三大『天道』之一，否则，无论外界如何喧嚣（Zone.js 捕获了多少异步事件），都休想让我出关（进行变更检测）。」

唤醒 `OnPush` 组件的三大「真言」#

一旦组件进入 OnPush 的「闭关」状态，只有三句「真言」能将它唤醒：

「父之赠」 —— @Input 引用变更

这是最重要、最核心的一句真言。只有当父组件传递给它的 @Input 属性，其引用发生了变化时，它才会醒来。
- 错误姿势：this.user.name = '雪狼'; （只改了属性，user对象的地址没变，组件睡得很香，毫无反应）
- 正确姿势：this.user = { ...this.user, name: '雪狼' }; （创建了一个全新的 user 对象，地址变了，组件被成功唤醒）
这句真言，强迫你走上「不可变数据」的光明大道。
「己之呼」 —— 组件内部事件触发

当组件自己的模板中，或其子孙组件的模板中，有事件被触发时（如 (click)），Angular 明白，这次交互很可能会改变组件自身的状态，所以它会主动唤醒该组件。
「流之召」 —— async 管道的新值

当你在模板中使用了 async 管道，并且这个管道所订阅的 Observable 发出了一个新值时，async 管道这位「贴身信使」，会精准地将该组件标记为需要检查。这是 async 管道的另一大美德。

5.告别“卡顿”：Angular中如何优化大型列表渲染

Mon, 01 Jan 0001 00:00:00 +0000

你的应用需要展示一个包含 10000 条联系人的通讯录。一个天真的想法是，直接用 @for 循环，把这 10000 条数据全部渲染成 DOM 节点。

这无异于打印一本一万页的电话黄页，然后「啪」的一声摔在用户面前。

结果可想而知：浏览器会因为需要同时渲染和管理成千上万个 DOM 元素而「当场去世」 —— 内存爆炸、页面卡死、用户愤怒地关闭标签页。渲染大型列表，是所有前端框架都会面临的经典性能挑战。今天，雪狼就传授你几招「化繁为简」的绝学，让你能优雅地驯服这头「性能巨兽」。

第一式：入门心法 `track` —— 每一个 `@for` 的「标配」#

这是基础，是内功，是你在使用 @for 时，必须养成的「肌肉记忆」。

痛苦之源：如果没有 track，每当你的列表数据发生任何一丁点变化（哪怕只是调换了两个元素的顺序），Angular 都会简单粗暴地销毁所有的 DOM 元素，然后再重新创建它们。
解救之道：提供一个 track 表达式，告诉 Angular 如何「识别」每一个列表项。
```
@for (item of items; track item.id) {

  <div>{{ item.name }}</div>

}
```
track 表达式中，item.id 应该返回一个唯一且稳定的标识符。
效果：现在，Angular 成了一位「火眼金睛」的管理者。当列表更新时，它能精确地知道哪些是新来的，哪些是离开的，哪些只是换了个位置。它只会对真正发生变化的 DOM 进行操作，大大减少了不必要的 DOM 销毁和创建。

请记住：任何使用 @for 循环的列表，都必须带上 track。 这是 Angular v17+ 的强制要求，也是性能的「本分」。

第二式：黑科技「空间折叠」 —— 虚拟滚动#

track 能解决数据更新时的卡顿，但它无法解决「初始渲染10000个 DOM」的性能原罪。要解决这个问题，我们需要祭出真正的「黑科技」 —— 虚拟滚动 (Virtual Scrolling)。

6.图片优化在Angular：如何让“图”飞起来，不拖累页面

Mon, 01 Jan 0001 00:00:00 +0000

在 Web 世界里，图片是情感的载体，是吸引用户眼球的利器。但它也是一把双刃剑。一张未经优化的图片，就像一件沉重无比的实心橡木家具，能轻易让你精心设计的、本该轻盈灵动的「房间」（页面）变得拥挤、迟缓，甚至让「房客」（用户）因为搬运（加载）时间过长而拂袖而去。

事实上，图片资源通常是拖慢网页速度的头号元凶。优化好它们，是性能优化里投资回报率最高的事情之一。今天，我们就来学习几招「炼金术」，让你页面上的「图」都能轻舞飞扬。

原罪：4000像素的「原图」直出#

犯罪现场：设计师给了你一张 4000x3000 像素、5MB 大小的精美 banner.png。你觉得很好看，直接在代码里写下了 <img src="assets/banner.png">，而它在页面上实际显示的尺寸只有 1200x450 像素。

恶果：

带宽浪费：用户被迫下载了一个比实际需要大十几倍的文件。在移动网络下，这简直是「谋财害命」。
LCP 灾难：作为页面的最大内容元素（LCP），这张巨图的下载和解码会耗费大量时间，导致页面核心内容迟迟无法展现。
内存爆炸：浏览器需要将这张 4000x3000 的大图解压到内存中，造成不必要的内存占用。

第一诫：永远不要使用尺寸超过其显示尺寸的图片。 在上传图片前，使用 Squoosh.app 或 PhotoShop 等工具，先将其裁剪到所需的最大显示尺寸。这是优化的第一步，也是最重要的一步。

良「材」善用：拥抱现代图片格式 WebP#

就像造家具有不同的木材，图片也有不同的「材质」（格式）。

老三样：JPEG（有损压缩，适合照片）、PNG（无损压缩，支持透明）、GIF（简单动画）。
新宠儿：WebP。这是由 Google 开发的现代图片格式，它集各家之所长，同时支持有损/无损压缩、透明度和动画。
核心优势：在肉眼可见的同等画质下，WebP 格式的图片体积通常比 JPEG 小 25-35%，比 PNG 小 26%。

策略：优先使用 WebP。对于需要兼容非常老旧浏览器的场景，可以使用 <picture> 元素做优雅降级：

<picture>
  <source srcset="image.webp" type="image/webp">
  <img src="image.jpg" alt="description">
</picture>

浏览器会自动选择它支持的第一个格式进行加载。

Angular 的「神兵利器」：`ngSrc` 指令#

你以为 <img src="..."> 只是一个简单的属性？在现代 Angular 中，我们有了更强大的武器 —— 来自 @angular/common 的 NgOptimizedImage 指令，通过 ngSrc 属性来使用。

它不仅仅是 src 的替代品，它是一位内置在框架里的「图片优化专家」。

7.Angular打包优化：瘦身成功的秘密，让你的应用更轻盈

Mon, 01 Jan 0001 00:00:00 +0000

你的应用写完了，功能完美，界面酷炫。你心满意足地敲下 ng build，然后看到 dist 文件夹里那个硕大无比的 main.js 文件，心头一凉。它就像一个你精心打扮的出游者，却背上了一个塞满各种非必需品的、重达百斤的登山包。

在 Web 的世界里，应用的「体重」（打包体积）至关重要。更重的「行李」意味着更长的「旅途时间」（加载速度），尤其是在网络不佳的移动端，用户可能在你的「行李」开箱之前，就已不耐烦地掉头离去。

JavaScript 的「昂贵」之处不仅在于下载，更在于浏览器主线程需要花费时间去解析、编译和执行它。因此，为你的应用「瘦身」，是性能优化中最具价值的一环。

Angular 的「全自动健身计划」：`ng build` 的幕后工作#

首先，你要知道，当你运行 ng build（默认使用 production 配置）时，Angular CLI 已经为你这位「健身者」安排了一套极其有效的「全自动健身计划」。

打包 (Bundling)：将你成百上千个 .ts 文件和第三方库，智能地合并成少数几个 JS 包，大大减少了网络请求的数量。
压缩 (Minification & Uglification)：剔除所有代码里的空格、换行、注释，并将变量名、函数名替换成简短的无意义字符（如 a, b, c）。这就像是给你的行李做了一次「真空压缩」。
摇树优化 (Tree-shaking)：这是最神奇的一步。编译器会像摇晃一棵大树，把枯枝败叶（未被使用的代码）全都摇下来。如果你引入了一个巨大的库，但只用到了其中的一个函数，Tree-shaking 会智能地分析 import/export 关系，确保最终打包进去的，只有你用到的那个函数及其依赖。
预编译 (AOT Compilation)：在打包时，就预先把所有 HTML 模板编译成高效的 JavaScript 代码。这样，浏览器在运行时就不再需要 Angular 编译器本身，不仅启动速度更快，也让编译器的代码可以从最终的包里被彻底移除，极大地减小了体积。

你的「主动锻炼」：高级瘦身秘诀#

光靠「自动健身计划」还不够，要练出「魔鬼身材」，还需要你这位「健身者」的主动锻炼和「饮食控制」。

第一招：惰性加载 —— 「少食多餐」的艺术#

这依然是减少初始包体积的「核武器」，重要性再怎么强调也不为过。通过惰性加载，你将那些非首屏必需的功能模块，从你的「主餐」（main.js 或其核心捆绑）中分离出去，变成用户「点餐」时才上的「配菜」。这能让你的应用「正餐」变得极小，实现「秒上」的效果。

第二招：包分析器 —— 体脂检测的「X 光」#

要想精准「减脂」，你得先知道「脂肪」堆在哪里。webpack-bundle-analyzer 就是你进行「体脂检测」的那台「X 光机」。

生成分析数据：

ng build --stats-json

这个命令会在打包的同时，在 dist/你的应用名/ 目录下生成一个 stats.json 文件。

8.性能监控与诊断：Angular应用的“健康体检报告”

Mon, 01 Jan 0001 00:00:00 +0000

你坚持健身，控制饮食，学习了各种养生技巧。但你怎么知道自己的身体是真的健康，还是处于「亚健康」状态？答案是：体检。

性能优化也是同理。你应用了惰性加载、OnPush、track……一顿操作猛如虎。但你的应用真的变快了吗？快了多少？瓶颈又转移到了哪里？

没有数据的优化，都是「凭感觉耍流氓」。

想要科学地、可持续地提升性能，你必须学会如何为你的 Angular 应用做一次全面的「健康体检」，并读懂体检报告。

两种体检：实验室（Lab） vs. 真实世界（Field）#

体检分为两种，两者互为补充，缺一不可。

实验室数据 (Lab Data)
- 是什么：在你自己的开发电脑上，在一个稳定、可控的环境中收集的性能数据。
- 好比是：在医院里做的「跑步机压力测试」。环境标准，结果可复现，便于对比两次「治疗」前后的效果。
- 优点：非常适合在开发阶段快速定位、调试和验证问题。
- 常用工具：Lighthouse, Angular DevTools, Chrome DevTools Performance。
真实用户数据 (Field Data / RUM)
- 是什么：从你遍布全球的、真实的用户那里收集来的性能数据。他们用着五花八门的设备、处在千奇百怪的网络环境中。
- 好比是：佩戴一个「24小时动态心电图」，记录你在真实生活中的各种数据。
- 优点：这才是性能的真相。它可能会告诉你，你的应用在你的顶配 MacBook 上快如闪电，但在印度用户手里的低端安卓机上却慢到无法使用。
- 常用工具：Google 的 CrUX 报告（通过 PageSpeed Insights 查看），或自己动手植入监控探针。

你的「诊疗包」：实验室诊断工具#

1. Lighthouse：「全科医生」#

这是你性能诊断的第一站。它内置于 Chrome 开发者工具的 Lighthouse 标签页中。

诊断方式：一键点击「Analyze page load」，它会模拟一个中端手机和中速网络，对你的页面进行一次全面的「体检」，并从性能、无障碍、最佳实践、SEO 四个维度给你的网站打分。
报告解读：它会直接告诉你 LCP、INP、CLS 等核心指标的得分，并给出非常具体、可操作的优化建议，比如「请为这张图片设置 priority 属性」、「请减少未使用的 JavaScript」等。

2. Angular DevTools Profiler：「心脏 B 超」#

这是专门为 Angular 应用打造的「心脏专科」诊断工具。你需要从浏览器商店安装 Angular DevTools 扩展。

Angular性能优化实践 on 雪狼的书斋

1.Angular应用“加速”秘籍：让你的用户不再等待！

性能优化的三大支柱#

支柱一：加载性能 —— 决定「第一印象」#

支柱二：运行时性能 —— 保证「丝般顺滑」#

2.Web Vitals与Angular：如何让你的应用在谷歌评分中“C位出道”

认识三位「评委」：LCP, INP, CLS#

1. LCP 评委 (Largest Contentful Paint) - 「视觉呈现」导师#

2. INP 评委 (Interaction to Next Paint) - 「交互响应」导师#

3. CLS 评委 (Cumulative Layout Shift) - 「舞台稳定」导师#

Angular 的「应试宝典」：逐个击破#

攻略一：冲刺 LCP (加载速度)#

3.Angular惰性加载：提升首屏速度的“障眼法”

什么是惰性加载？ —— 「按需点餐」的智慧#

为何惰性加载是性能优化的「第一杀手锏」？#

如何施展「障眼法」：从 loadChildren 到 loadComponent#

方式一：惰性加载一个独立组件 (loadComponent)#

方式二：惰性加载一组路由 (loadChildren)#

4.变更检测策略：Angular性能优化的“葵花宝典”

默认之「咒」：草木皆兵的 CheckAlways#

宝典心法：OnPush 的「闭关」誓言#

唤醒 OnPush 组件的三大「真言」#

5.告别“卡顿”：Angular中如何优化大型列表渲染

第一式：入门心法 track —— 每一个 @for 的「标配」#

第二式：黑科技「空间折叠」 —— 虚拟滚动#

6.图片优化在Angular：如何让“图”飞起来，不拖累页面

原罪：4000像素的「原图」直出#

良「材」善用：拥抱现代图片格式 WebP#

Angular 的「神兵利器」：ngSrc 指令#

7.Angular打包优化：瘦身成功的秘密，让你的应用更轻盈

Angular 的「全自动健身计划」：ng build 的幕后工作#

你的「主动锻炼」：高级瘦身秘诀#

第一招：惰性加载 —— 「少食多餐」的艺术#

第二招：包分析器 —— 体脂检测的「X 光」#

8.性能监控与诊断：Angular应用的“健康体检报告”

两种体检：实验室（Lab） vs. 真实世界（Field）#

你的「诊疗包」：实验室诊断工具#

1. Lighthouse：「全科医生」#

2. Angular DevTools Profiler：「心脏 B 超」#

如何施展「障眼法」：从 `loadChildren` 到 `loadComponent`#

方式一：惰性加载一个独立组件 (`loadComponent`)#

方式二：惰性加载一组路由 (`loadChildren`)#

默认之「咒」：草木皆兵的 `CheckAlways`#

宝典心法：`OnPush` 的「闭关」誓言#

唤醒 `OnPush` 组件的三大「真言」#

第一式：入门心法 `track` —— 每一个 `@for` 的「标配」#

Angular 的「神兵利器」：`ngSrc` 指令#

Angular 的「全自动健身计划」：`ng build` 的幕后工作#