2026年了，Angular 里的 RxJS 订阅真的需要一个个手动退订吗？

Angular 的 RxJS 订阅，并不是每一条都非得手动取消。严格说，只有那些不会自动结束、并且回调仍会引用组件实例的订阅，才需要担心拖住组件导致回收不了。2026 年项目交付中的主流做法已变成：先回答“这个 Observable 会在什么时候结束、由谁结束”；大多数模板绑定交给 async 管道，组件内普通的订阅交给 takeUntilDestroyed，手动 unsubscribe 只留给需要按业务时刻中途停止的少数场景。记住这个结论，可以减少大量模板代码和评审争论。

先判断：到底哪类订阅才不会自动结束

内存泄漏通常要满足两个条件：一，Observable 长期活跃不会 complete；二，订阅回调中还保存着组件实例或组件引用的对象。实际排查时，只关心“会不会 complete”远远不够，因为回调在组件销毁后仍然执行，会带来两种可见问题：一是继续修改已销毁组件的属性，容易在控制台看到警告；二是重新触发组件内的方法或依赖注入的服务，造成额外的请求或状态污染。

因此可以把 Observable 分成两类：

• 会自然结束的有限流，例如 HttpClient 发出的响应、first()、take(1)、of() 等普通请求或常量流，通常不会长期占有订阅。
• 不自动结束的无限流，例如 interval、fromEvent、Subject、merge、switchMap 等事件或推送源，它们也不会自己 complete，需要外部主动停止。

但请注意：即便是会自然结束的 HttpClient，如果接口回包足够慢，而用户已经离开页面，回调中仍可能在组件销毁后执行 this.loading = false。虽然不会内存泄漏，它也可能触发变更检测的警告。因此最终要处理的不是“所有订阅”，而是“所有在组件销毁后仍可能执行的回调”。

三步核对法：一个订阅要不要手动退订

与其背“每个 subscribe 都要配 unsubscribe”，不如在代码评审时按下述顺序核对三步，顺序乱了容易误判：

1. 先看源会不会自己 complete。会的话通常可以从内存泄漏候选里排除；若回调中仍有组件引用，则问题变成“异步回调时机”而不是“订阅泄漏”。
2. 再看回调是否引用组件实例或 DOM。如果回调里只调用了独立服务和全局状态，不引用 this 或模板元素，那么即使 Observable 长存，组件实例依然可被回收，不必专门退订。但若在类中引用了 this.xxx，就要继续往下走。
3. 最后看生命周期内有没有更干净的方案。Angular 16 之后有 takeUntilDestroyed，模板中也可以直接用 async 管道。只要能把订阅和组件生命周期绑定，就不需要手动退订。只有当订阅必须按业务时刻提前停止、或无法用生命周期方案表达时，才安排 unsubscribe。

这三步分别对应“要不要担心泄漏”“泄漏发生在谁身上”“有没有不写手动的替代”。三步都过完，你看到的订阅拆解就会清晰很多。

方案对比：手动 unsubscribe、async 管道、takeUntilDestroyed

三种方式不是谁更高级，而是各自解决的问题不同。下面是常见分工，你可以把它当验收清单：

• 手动 unsubscribe：适合必须按业务时刻停止的订阅，例如点击“开始轮询”后每隔几秒拉一次接口，点击“停止轮询”时立即退订。优点是可精确控制结束时机；缺点是退订散落在业务逻辑中，一旦分支增多容易漏写。
• async 管道：适合模板直接展示的 Observable。用法类似 data$ | async，在组件销毁时会自动退订，逻辑最简单；但不适合需要在组件方法中主动取当前值的场景。
• takeUntilDestroyed：适合组件或服务中大部分需要注册后随宿主销毁的订阅，例如用 fromEvent 监听滚动、用 interval 轮询，再配合 takeUntilDestroyed。它在 Angular 16 之后作为独立 API 提供，使用前要确认项目 Angular 版本。它能减少散落的 unsubscribe，但不是所有版本都可用，旧版本可用 takeUntil 手动注入 destroyed$ 变量。

从我们交付过的十几个中后台项目情况看，常见区间是六到八成可以由 async 管道或 takeUntilDestroyed 覆盖，剩下的一到两成真正需要手动退订。如果手动退订占比明显超过三成，通常意味着把生命周期内本该自动结束的流也写成了业务手动停止。

项目现场：一次订阅治理，少了半天到一天的返工教训

2026 年年初，我们给一个运行了三年的 Angular 后台做性能整改。约束是：不改业务行为，上线窗口只有两天，代码里散落了上百处直接 subscribe，没有统一销毁策略，浏览器内存持续增长。

做法分四步：先拉出所有订阅清单，按“是否在 service 中、是否自动完成、是否引用组件字段”分类；第二步把模板直接消费 Observable 的字段全部改成 async 管道；第三步把组件内无限流统一迁移到 takeUntilDestroyed；最后一步只保留三处业务上需要中途停止的轮询，继续用手动 unsubscribe。

结果内存下降明显，但初次切换后出现了一个意外：有三处页面原本依赖“离开页面后订阅仍存活”，去更新其他页面上的待办角标。takeUntilDestroyed 提前结束订阅后，角标不再自动刷新。我们只能把这类跨页面数据流移到全局单例 Subject，再由其他页面各自按需订阅，返工调整用了约半天到一天。这就是一次真实代价，经验区间是：若改造前没有梳理“订阅是否跨页面存活”，返工时间会额外增加半天到一天，超过预留窗口。

常见坑与验收标准

常见的坑有三个。第一个是搞一刀切，让所有 subscribe 都写 unsubscribe，连 HttpClient 都手动退订，代码量和 reviewer 负担都变大，收益却很小。第二个是只看内存快照，忽视回调在销毁后继续执行造成的问题，比如重复调用接口、设置已销毁组件属性后出现 ExpressionChangedAfterItHasBeenCheckedError。第三个是在动态创建的服务中使用 takeUntilDestroyed 却对整个生命周期理解有误，可能提前把共享流结束，影响到其他组件。

验收时可以参考四条，按顺序过：一，进入和退出页面若干次后，Memory 快照没有持续递增；二，组件类中几乎看不到裸的 subscribe(() => {})，需要订阅的地方都统一配了销毁机制；三，模板中的异步数据绑定大多来自 async 管道，而不是在组件类里手动赋值；四，代码评审中新增的每个 subscribe 都能答复“这个 Observable 什么时候结束、由谁结束”。如果答复不了，默认套用生命周期感知方案。

适用场景与边界

这套判断逻辑适合正在维护中大型 Angular 业务应用的团队，尤其是需要长列表、弹窗、轮询、推送提醒和状态共享的场景。它关注的不是“退订写法”，而是“订阅和回调的生命周期责任”。

但并非所有项目都适用。一次性演示页、短生命周期活动页、原型验证里，即使不手动退订也不会出现可感知的内存问题，强行引入 takeUntilDestroyed 只会增加复杂度。全局单例服务（例如 root 级 Service）中的订阅如果本来就应当与 App 同生命周期，就不需要随某个页面销毁而退订；这时你甚至不应该在服务方法里用 takeUntilDestroyed 把它结束，否则可能切断其他页面正在使用的流。另一个边界是跨组件共享的 Subject：如果多个组件都要消费同一个数据源，正确做法是把订阅放在各自组件中并使用生命周期感知销毁，而不要在共享服务里用一个“全局退订”把它们一刀切断。

常见问题

Angular 项目中用了 async 管道，还需要手动 unsubscribe 吗？

不需要。async 管道会在组件销毁时自动退订，模板绑定场景直接使用即可。剩下需要手动处理的场景是脱离模板后仍要主动控制流，或需要拿当前值。

HttpClient 请求不手动退订，会不会造成内存泄漏？

普通 HttpClient 请求会正常完成并释放连接，不会造成内存泄漏。需要关注的是接口较慢时页面已关闭，回调仍会执行，建议用 takeUntilDestroyed 保护一下，避免操作已销毁组件。

takeUntilDestroyed 和手动 unsubscribe 怎么选？

组件内普通异步流程优先用 takeUntilDestroyed；只有必须按业务时机停止，而不是等组件销毁时才停止的订阅，才需要手动 unsubscribe。

服务里的订阅要不要手动取消？

应用级单例服务与 App 同生命周期，通常不需要退订；如果服务是组件动态创建并应随之销毁，则要确保订阅也使用生命周期感知销毁。

不取消订阅一定会导致内存泄漏吗？

不一定。无限流且回调引用了组件实例时才容易拖住组件；有限流不会。但为了统一维护和避免异步回写，更推荐用 async 管道或 takeUntilDestroyed 收口。

给团队的建议：把订阅生命周期检查加入日常评审清单，每次写 subscribe 前先回答“会不会自己结束”“回调有没有引用组件”“能否用生命周期感知方案”。如果不确定，先用 Memory 快照观察一段时间，再决定有没有治理必要，别照搬旧项目的“每条订阅都需要退订”。