• 文档
• 教程
• 知识库

导读

本文围绕 developer-roadmap 仓库中 Angular 路线图收录的 Zoneless 主题，系统讲解 Angular 18 引入的实验性无 Zone（zoneless）变更检测能力：它如何取代 Zone.js、带来更快的初始渲染、更小的打包体积与更简单的调试体验，以及开发者如何在实际项目中启用并平滑迁移。读完本文，你将掌握 zoneless 的原理、provideZonelessChangeDetection()的配置方式、状态通知机制（Signals / 事件监听 /markForCheck），以及迁移时的兼容性要点。

背景：Zone.js 是如何驱动 Angular 变更检测的

在理解 zoneless 之前，需要先弄清 Zone.js 在传统 Angular 应用中的角色。仓库内 Zones 文档明确指出：

Zone.js 是一种信号机制（signaling mechanism），Angular 用它来检测应用状态是否可能发生了变化。它会捕获setTimeout、网络请求、事件监听等异步操作，Angular 基于 Zone.js 发出的信号来调度变更检测。

与之配合的是 变更检测 机制：Angular 自上而下遍历组件树，检查应用状态是否变化、是否需要更新 DOM，并周期性地运行变更检测，使数据模型的改动反映到视图上。变更检测既可以手动触发，也可以通过异步事件触发。

也就是说，传统架构下这条链路是这样的：

1. 浏览器异步 API（定时器、Promise、XHR、DOM 事件等）被 Zone.js 打补丁（patch）；
2. 任意异步任务结束，Zone.js 通知 Angular "可能有状态变化"；
3. Angular 运行一轮变更检测，遍历组件树比对并更新视图。

这套机制从 Angular 诞生之初就存在，但它有一个明显的问题：Zone.js 捕获的是"所有"异步活动，而不是"真正改变了状态"的活动。

Zone.js 的代价：Zone Pollution 与不必要的变更检测

仓库内 Zone Pollution 文档点出了 Zone.js 的核心弊端：

在某些情况下，被调度的任务或微任务并不会改变数据模型，却仍然触发了变更检测，而这些变更检测其实毫无必要。常见的例子包括requestAnimationFrame、setTimeout和setInterval。

例如一个setInterval定时器即使每 100ms 只做一次与状态无关的轻量计算，也会驱动 Angular 反复执行整棵组件树的变更检测；多个第三方库同时使用定时器、动画帧、长轮询时，这种"噪声触发"会被进一步放大，产生典型的 Zone Pollution 问题。

针对这个问题，传统方案是"把代码挪出 Angular zone"（NgZone.runOutsideAngular），或用 Angular DevTools 定位频繁的变更检测周期——但这些都是事后补救，Zone.js 本身的运行时开销与补丁机制依然存在。Zoneless 的出发点正是从架构层面移除这个中间层。

什么是 Zoneless：Angular 18 引入的实验性变更检测

zoneless 应用（Zoneless Applications）是 Angular 18 引入的实验特性，核心文档 zoneless-applications 给出了明确定义：

Angular 18 引入了一个名为 zoneless change detection 的实验性特性。这项技术移除了对Zone.js的依赖——Zone.js 是 Angular 自诞生起就用于变更检测的库。通过消除 Zone.js，Angular 应用可以获得更快的初始渲染、更小的包体积和更简单的调试。

一句话概括：zoneless 不再依赖"谁动了浏览器 API"这种全局信号，而是让框架精确地知道"什么状态发生了变化"。Angular 之所以能做到这一点，根本原因在于 Signals 体系的落地。仓库内 Signals 文档说明：

Angular Signals 是一个能够细粒度追踪状态在应用中被如何使用、在哪里被使用的系统，它允许框架优化渲染更新。

有了信号这种细粒度追踪，框架便可以从"广撒网式"的变更检测，转向"按需精确更新"，这正是 zoneless 可行的技术基础。

关键收益：为什么值得迁移

更快的初始渲染：启动阶段不再需要 patch 全局浏览器 API、不再维护 zone 上下文，框架可以更快完成首次渲染；更小的包体积：zone.js 作为独立运行时依赖被整体移除，产物中少了一份不小的 JS 开销；更简单的调试：不再有"一个setTimeout就触发一轮变更检测"的干扰，Angular DevTools 中看到的变更检测周期与实际状态变化一一对应。

值得一提的是，该特性在 Angular 18 中标注为实验性，此后版本迭代中官方持续推进其稳定化，新项目已可将其作为默认架构选项来评估。

实战：如何启用 Zoneless

启用 zoneless 的核心 API 是provideZonelessChangeDetection()，它来自@angular/core，用于取代默认的provideZoneChangeDetection()。

方式一：基于bootstrapApplication（standalone 应用）

// main.ts import { bootstrapApplication } from '@angular/platform-browser'; import { provideZonelessChangeDetection } from '@angular/core'; import { AppComponent } from './app/app.component'; bootstrapApplication(AppComponent, { providers: [ provideZonelessChangeDetection(), // 其他 provider，如 provideRouter(routes) 等 ], });

方式二：基于NgModule

// app.module.ts import { NgModule } from '@angular/core'; import { provideZonelessChangeDetection } from '@angular/core'; @NgModule({ declarations: [AppComponent], imports: [BrowserModule], providers: [ provideZonelessChangeDetection(), ], }) export class AppModule {}

与历史方案ngZone: 'noop'的区别

在 zoneless 正式出现之前，开发者常通过ngZone: 'noop'禁用 Zone.js 补丁来"手动"控制变更检测，但那样做之后必须自己负责在状态变化时通知 Angular，稍有不慎视图就不会更新。zoneless 的不同在于：它保留了一套完整的"通知机制"——信号、模板事件、显式标记——框架依然能在正确的时间点自动刷新视图，只是不再依赖 zone 的全局补丁。

Zoneless 下变更检测靠什么触发

启用 zoneless 后，以下三类信号会驱动变更检测：

1. Signals 状态变化

使用 Angular Signals 管理状态时，模板会自动订阅并在信号变化时精确更新：

import { Component, signal } from '@angular/core'; @Component({ selector: 'app-counter', template: ` <p>当前计数：{{ count() }}</p> <button (click)="increment()">+1</button> `, }) export class CounterComponent { count = signal(0); increment() { this.count.update((value) => value + 1); } }

由于信号本身记录了"被谁读取、在哪里使用"，count()一旦变化，框架无需扫描整棵组件树即可知道CounterComponent的模板需要刷新。

2. 模板事件监听

通过 Angular 模板语法注册的事件（如上面的(click)）也会自动通知框架执行变更检测，因此"交互导致更新"这一最常见的场景无需额外代码。

3. 显式通知：ChangeDetectorRef.markForCheck()

对于无法用信号表达的状态（例如与第三方库对接、修改了非信号字段），需要显式告知框架：

import { Component, inject, ChangeDetectorRef } from '@angular/core'; @Component({ ... }) export class ChartComponent { private cdr = inject(ChangeDetectorRef); // 第三方图表库回调：框架无法感知其内部状态变化 onExternalDataUpdate() { this.cdr.markForCheck(); } }

markForCheck()的作用是"从当前组件开始向上标记为需要检查"，这与ChangeDetectionStrategy.OnPush的既有语义一致，是 zoneless 架构下最直接的兜底手段。

异步数据流：rxjs-interop 与async管道

组件若通过Observable提供数据，zoneless 下依然可以正常工作：async管道在收到新值时内部会标记组件需要检查；同时仓库 Angular 路线图还收录了 rxjs-interop 相关内容，toSignal()等互操作 API 可以把流式数据转换为信号，让模板的更新路径完全统一到信号机制上。

迁移与兼容性要点

从 Zone.js 迁移到 zoneless，需要注意以下几类差异：

1. 状态管理优先信号化：新代码应优先使用signal()/computed()/input()等信号 API（可参考 inputs-as-signals、queries-as-signals），对于绕不开的"非信号状态"，显式调用markForCheck()。
2. 生命周期钩子仍然存在：组件生命周期机制不受影响，ngOnChanges、ngDoCheck等钩子依旧按 component-lifecycle 文档描述的方式执行；需要留意的是，由于变更检测不再被无关异步任务触发，ngDoCheck这类"每轮 CD 都执行"的钩子执行频率会更贴近真实状态变化。
3. NgZone相关 API 语义变化：NgZone.onMicrotaskEmpty等基于 zone 事件的 API 在 zoneless 下不再有对应的触发源，依赖它们的代码需要改用信号、markForCheck或 rxjs-interop 方案。
4. 第三方库适配：若第三方库内部修改了组件字段却不通过信号或事件暴露，视图可能不刷新，此时通过markForCheck()显式接管是标准做法。
5. 实验特性约束：在 Angular 18 中该能力标记为 experimental，生产环境启用前应结合自身依赖情况做充分验证；后续版本已逐步将其转为稳定能力，迁移路径也趋于成熟。

调试与性能实践

• 用 Angular DevTools 验证：安装 DevTools 浏览器扩展后，可以直观查看组件树与每一次变更检测周期。zoneless 应用里，DevTools 中记录到的 CD 周期应当与真实状态变化一一对应，若发现异常频繁的检测，排查方向会更清晰。
• 与既有性能策略协同：仓库内 性能优化 文档提到的 Deferrable Views（延迟加载视图）、图片优化、Hydration（水合）等策略与 zoneless 并不冲突；zoneless 解决的是"变更检测触发源头"的问题，两者叠加可以获得更完整的运行时性能提升。
• 留意慢计算：即便消除了 zone 噪声，每次变更检测仍会同步求值模板表达式并执行相关生命周期钩子（详见 Slow Computations），因此纯管道缓存、算法优化等手段在 zoneless 应用中依然必要。

适用前提与限制小结

• 启用 zoneless 需要显式调用provideZonelessChangeDetection()（或用ngZone: 'noop'演进到该方案），默认的ng new模板仍基于 Zone.js，属于显式 opt-in 的实验能力；
• 应用的状态更新路径必须可被框架感知（信号 / 模板事件 /markForCheck），否则会出现"数据变了但视图没刷新"的问题；
• 若项目大量依赖基于 Zone.js 自动触发的第三方库或旧式状态管理写法，建议先在隔离的 feature 分支或小规模模块中验证再全面铺开。

继续学习：仓库内相关资源

• Zoneless Applications（本文主题文档）
• Zones：Zone.js 信号机制
• Change detection：变更检测总览
• Zone Pollution：无用变更检测的成因
• Signals：细粒度状态追踪系统
• rxjs-interop：流式数据与信号互操作
• Component Lifecycle：组件生命周期钩子
• Performance：运行时性能优化总览
• DevTools：变更检测周期的调试与剖析

• 文档
• 教程
• 知识库