Angular应用中真实场景下常见长期运行页面内存泄漏的典型来源，从遗忘的订阅到ElementRef引用泄露的定位与全面治理方案

一、先聊点实在的——为什么你的页面越用越卡

你是不是也遇到过这种情况？一个后台系统开了一整天，刚开始点哪儿都跟飞一样，到了下午点个按钮要转三圈，鼠标也感觉沉沉的，甚至浏览器直接弹出“页面无响应”。如果你用的是Angular开发的单页应用，那八成是内存泄漏在作祟。

内存泄漏这个词听着高大上，说白了就是程序在使用内存的时候，用完没归还。就像你借了本工具书看完随手放在床头，一直没还回书架，床头堆的书越来越多，最后连放杯子的地方都没了。浏览器里的内存也是一样，对象占用了内存，但没有任何代码再需要它了，可是垃圾回收机制又没法把它清掉，这些内存就被白白占着。对长期运行的页面来说，泄漏一点点不怕，怕的是日积月累，最终把浏览器拖垮。

Angular有一个特别强大的依赖注入系统和响应式编程库RxJS，用起来很顺手，但恰恰是这些方便的工具，容易埋下泄漏的种子。接下来我们就从最常见的场景说起，看看那些“无人认领”的订阅是怎么把内存一点点吃掉的。

二、内存泄漏的根源：那些被遗忘的订阅

如果你在Angular里用过HttpClient发请求，或者用RxJS做事件流处理，那你应该对subscribe方法不陌生。每当你调用observable.subscribe()，就相当于告诉这个数据流：“喂，以后每次有新数据，都通知我一声。”这个“我”是谁？是你的组件。组件需要在收到数据后更新界面，所以这个“通知”关系会一直保留着。

问题在于，Angular组件是有生命周期的。比如你打开一个详情弹窗，关闭时组件会被销毁。组件销毁了，但那个“通知”关系可能还留在数据流的调度中心里。于是数据流只要还活着，未来某个时刻依然会往这个已经被销毁的组件上发消息。组件明明已经死了，却因为被订阅引用住，垃圾回收器一看“这对象还有人拿着”，就不敢回收。于是一个组件占用的所有资源，包括它关联的DOM、指令、依赖服务，统统留在内存里。页面开得越久，组件被创建销毁的次数越多，这种“僵尸组件”就越多，内存自然越吃越紧。

2.1 一个活生生的例子：定时器泄漏

最容易理解的就是用RxJS的interval写个定时器。假设我们要做一个倒计时显示，组件里每隔一秒更新一次数字。

// 技术栈：Angular 12+ / TypeScript 4+
import { Component, OnDestroy, OnInit } from '@angular/core';
import { interval } from 'rxjs';

@Component({
  selector: 'app-count-down',
  template: `
    <div>剩余时间：{{ count }} 秒</div>
  `,
})
export class CountDownComponent implements OnInit {
  count = 10;

  ngOnInit(): void {
    // 每秒钟发出一个递增的数字，然后更新组件里的 count
    interval(1000).subscribe((value) => {
      this.count = 10 - value;
      // 如果 count 变到 0 以下就不再显示负数
      if (this.count < 0) {
        this.count = 0;
      }
    });
  }
}

这段代码写起来特别自然，对吧？在ngOnInit里启动一个定时器，每秒钟更新一次界面。可是问题来了：组件销毁后，那个interval并没有停止。它每秒钟还在发送数字，而这个订阅回调里还在尝试修改this.count。组件已经没了，但this指向的对象还被interval的内部调度器引用着。时间一长，每打开一次页面，就多出来一个永远停不下来的定时器，它的回调里还拉着原来的组件实例不放。结果就是页面上的定时器越来越多，内存占用像滚雪球一样。

2.2 正确的“地下党员”接头方式：OnDestroy退订

要解决这个问题，最直白的方式就是让组件在销毁前主动取消订阅。就像地下党撤退前要销毁所有联络暗号一样。

// 技术栈：Angular 12+ / TypeScript 4+
import { Component, OnDestroy, OnInit } from '@angular/core';
import { interval, Subscription } from 'rxjs';

@Component({
  selector: 'app-count-down',
  template: `
    <div>剩余时间：{{ count }} 秒</div>
  `,
})
export class CountDownComponent implements OnInit, OnDestroy {
  count = 10;
  // 用一个成员变量来持有这个订阅对象
  private subscription: Subscription | null = null;

  ngOnInit(): void {
    // 把订阅对象存起来，方便后面退订
    this.subscription = interval(1000).subscribe((value) => {
      this.count = 10 - value;
      if (this.count < 0) {
        this.count = 0;
      }
    });
  }

  ngOnDestroy(): void {
    // 要退订就退订干净，不能留尾巴
    this.subscription?.unsubscribe();
  }
}

这里用了一个Subscription类型的变量来保存订阅对象，然后在ngOnDestroy生命周期钩子里调用unsubscribe()。这样当组件销毁时，定时器也就被清理了。不过你可能已经看出来了，如果一个组件里有多个订阅，每个订阅都要手动保存、手动退订，代码会变得很啰嗦。而且万一某个订阅忘了保存，又回到泄漏的老路上去了。

三、一个典型的混合泄漏场景：订阅+服务单例

除了定时器，还有一类特别隐蔽的泄漏跟“服务单例”一起出现。Angular里的服务默认是单例的，也就是说整个应用共享同一个服务实例。如果某个组件在初始化时，往一个全局服务里塞了一份自己的引用，而服务又不销毁，那么这个组件就永远无法被垃圾回收。

3.1 演示：一个妥妥的泄漏现场

我们假设有一个通知服务，它负责收集页面上所有弹窗组件的实例，集中管理。

// 技术栈：Angular 12+ / TypeScript 4+
import { Injectable } from '@angular/core';
import { ToastComponent } from './toast.component';

@Injectable({ providedIn: 'root' })
export class ToastManagerService {
  // 这个数组里存放了所有尚未关闭的 Toast 组件实例
  private toasts: ToastComponent[] = [];

  // 把组件实例注册进来
  registerToast(toast: ToastComponent): void {
    this.toasts.push(toast);
  }

  // 获取所有组件实例
  getToasts(): ToastComponent[] {
    return this.toasts;
  }
}

然后，我们的ToastComponent在构造器里就把自己注册到这个服务里。

// 技术栈：Angular 12+ / TypeScript 4+
import { Component, OnInit } from '@angular/core';
import { ToastManagerService } from './toast-manager.service';

@Component({
  selector: 'app-toast',
  template: `
    <div class="toast">这是一条短暂的提示消息</div>
  `,
})
export class ToastComponent implements OnInit {
  constructor(private toastService: ToastManagerService) {}

  ngOnInit(): void {
    // 把当前组件实例注册到全局服务中
    this.toastService.registerToast(this);
  }
}

你以为这个组件显示几秒后就会被销毁，实际上呢？它被ToastManagerService里的toasts数组死死攥着。ToastManagerService是根级单例，应用不退出它就永远活着。哪怕ToastComponent的DOM已经被移除，Angular也已经把它标记为销毁，但只要数组里还有它的引用，垃圾回收器就认为“这个对象还有人用”，于是内存里就留下了一个完整的组件对象，以及它关联的视图数据、DOM节点等。

3.2 治理思路：不要持有组件实例

正确的做法是，服务里只保存必要的数据，而不是整个组件对象。比如我们可以让服务只保存“需要显示的消息文本”，组件自己去订阅这个数组，或者用Angular内置的AsyncPipe来自动处理订阅生命周期。

// 技术栈：Angular 12+ / TypeScript 4+
import { Injectable } from '@angular/core';
import { BehaviorSubject } from 'rxjs';

@Injectable({ providedIn: 'root' })
export class ToastManagerService {
  // 使用 BehaviorSubject 来广播最新的消息列表
  private toastMessages = new BehaviorSubject<string[]>([]);

  // 外部通过这个字段来获取可订阅的数据流
  readonly messages$ = this.toastMessages.asObservable();

  addMessage(message: string): void {
    const current = this.toastMessages.getValue();
    this.toastMessages.next([...current, message]);
  }
}

然后在组件里，只需要用AsyncPipe订阅，再也不用手动管理订阅了：

// 技术栈：Angular 12+ / TypeScript 4+
import { Component } from '@angular/core';
import { ToastManagerService } from './toast-manager.service';

@Component({
  selector: 'app-toast-list',
  template: `
    <div *ngFor="let msg of toastManager.messages$ | async" class="toast">
      {{ msg }}
    </div>
  `,
})
export class ToastListComponent {
  constructor(public toastManager: ToastManagerService) {}
}

AsyncPipe会在组件销毁时自动取消订阅，而且不会在服务里留下组件实例。这种数据驱动的设计，不但减少了内存泄漏的风险，还让组件变得很干净，只管显示数据。这里顺便提一句，AsyncPipe是Angular内置的一个好东西，它能自动订阅和退订，平时用的时候尽量优先选择它，比手动调subscribe省心多了。

四、不只是订阅——ElementRef 引用泄露

内存泄漏还有一个重要来源，就是直接操作DOM后留下的“路过不留痕”的引用。很多老手会在Angular里用ElementRef，或者用document.querySelector拿一个DOM节点。拿完就存到组件变量里，组件销毁时忘了清空。于是这个DOM节点被组件引用着，组件又被某个服务引用着，一层套一层，谁也跑不掉。

4.1 示例：把DOM引用装在数组里不撒手

假设你做一个富文本编辑器，需要实时统计页面里所有图片元素的位置。

// 技术栈：Angular 12+ / TypeScript 4+
import { Component, ElementRef, AfterViewInit, OnDestroy, QueryList, ViewChildren } from '@angular/core';

@Component({
  selector: 'app-image-list',
  template: `
    <div class="gallery">
      <img *ngFor="let img of images" [src]="img" class="photo" />
    </div>
  `,
})
export class ImageListComponent implements AfterViewInit, OnDestroy {
  @ViewChildren('photo') private photoElements!: QueryList<ElementRef<HTMLImageElement>>;
  images = ['a.jpg', 'b.jpg', 'c.jpg'];

  ngAfterViewInit(): void {
    // —— 这里把拿到的DOM引用全都存进了一个成员变量里
    this.photoElements.forEach((elementRef) => {
      this.photoRefs.push(elementRef.nativeElement);
    });
  }

  // 成员变量，存放所有图片元素的引用
  private photoRefs: HTMLElement[] = [];

  ngOnDestroy(): void {
    // —— 注意！这里没有清空 photoRefs 数组
    // 即使组件销毁了，photoRefs 依然指向这些 DOM 节点
  }
}

问题就出在这个photoRefs数组。组件销毁时，Angular会移除自己的视图DOM，但是因为photoRefs里还保存着这些DOM节点的引用，垃圾回收器一看“DOM节点还被引用着”，就不会回收它们。更糟糕的是，这些DOM节点可能还关联着事件监听器、数据绑定，它们占用的内存可不少。时间一长，你滚动页面、打开弹窗、又关闭，每次都留下一堆孤零零的DOM节点，内存就被碎片填满了。

4.2 怎么治理？销毁时清空引用

最简单的办法就是在ngOnDestroy里把数组清空，断开引用关系。另外，尽量使用Angular的TemplateRef或ViewChild配合数据驱动，不要长期持有原生DOM。

// 技术栈：Angular 12+ / TypeScript 4+
import { Component, ElementRef, AfterViewInit, OnDestroy, QueryList, ViewChildren } from '@angular/core';

@Component({
  selector: 'app-image-list',
  template: `
    <div class="gallery">
      <img *ngFor="let img of images" [src]="img" class="photo" />
    </div>
  `,
})
export class ImageListComponent implements AfterViewInit, OnDestroy {
  @ViewChildren('photo') private photoElements!: QueryList<ElementRef<HTMLImageElement>>;
  images = ['a.jpg', 'b.jpg', 'c.jpg'];

  // 这个数组只是临时存放，用完之后必须清空
  private photoRefs: HTMLElement[] = [];

  ngAfterViewInit(): void {
    this.photoElements.forEach((elementRef) => {
      this.photoRefs.push(elementRef.nativeElement);
    });
    // 这里可以做一些初始化工作，比如计算位置
    this.calculatePositions();
    // 结束后立即释放引用，绝不长期保存
    this.photoRefs = [];
  }

  private calculatePositions(): void {
    // 模拟一下计算
    this.photoRefs.forEach((element) => {
      const rect = element.getBoundingClientRect();
      console.log('图片位置', rect.top, rect.left);
    });
  }

  ngOnDestroy(): void {
    // 保险起见，再清一次
    this.photoRefs = [];
  }
}

这里的关键思想是：能不存就不存，存了要舍得清。如果你非要长期保留一个DOM引用，那一定要确保在组件销毁时把这个引用置为null或者从数组里删除。

五、其他常见的长期运行页面泄漏来源

除了上面说的订阅和DOM引用，还有几个地方特别容易让内存悄悄溜走。

5.1 全局事件监听器

你在组件里给window或者document挂了一个事件监听器，比如监听窗口滚动、键盘事件。组件销毁时，如果忘了移除监听器，那么监听器回调里绑定的组件对象就会被全局对象一直引用。这样组件永远清理不掉。

// 技术栈：Angular 12+ / TypeScript 4+
import { Component, HostListener, OnDestroy } from '@angular/core';

@Component({
  selector: 'app-scroll-tracker',
  template: `<div>滚动监听中...</div>`,
})
export class ScrollTrackerComponent implements OnDestroy {
  // 使用 Angular 的 HostListener 装饰器来监听窗口滚动
  @HostListener('window:scroll', ['$event'])
  onScroll(event: Event): void {
    console.log('滚动位置：', window.scrollY);
  }

  ngOnDestroy(): void {
    // HostListener 在组件销毁时会自动移除监听，这很好。
    // 但是如果你使用原生 addEventListener，就必须手动移除。
  }
}

用@HostListener装饰器，Angular会在组件销毁时自动帮你移除监听器。但如果你图方便，在ngOnInit里写window.addEventListener('scroll', this.myHandler)，那么ngOnDestroy里必须配对写上window.removeEventListener('scroll', this.myHandler)。这里特别提醒一句：如果你传进去的回调是箭头函数或者bind出来的新函数，那removeEventListener必须持有同一个函数引用，否则移除是失败的。

5.2 定时器你清了，但你的闭包没清

有些人知道用setInterval要清理，于是在ngOnDestroy里调用了clearInterval。但你可能没有意识到，定时器的回调函数如果捕获了组件里的数据，那么即使定时器本身清掉了，这个闭包也可能被别的地方引用着。比如你把回调函数传给了某个服务，服务又一直保存着，那闭包里的组件引用就泄漏了。所以，要时刻记得：不光是定时器，任何回调函数只要被外部对象引用，你就要小心它捕获了什么东西。

5.3 变懒的懒加载路由

Angular的懒加载模块本身是会被卸载的。但是如果某个懒加载模块里的服务被注册到了根注入器，那它就会变成单例，永远不会被销毁。比如你在某个特性模块的providers数组里写了{ provide: SomeService, useClass: SomeService }，但这个模块被路由懒加载，只要这个模块被加载过，这个服务实例就会一直存在。如果这个服务里又缓存了组件数据，那内存就收不回来了。建议把服务注册在模块级或者组件级，除非你确定这个服务需要全局单例。

六、怎么定位泄漏？靠前端的“法医”工具

明白了泄漏的来源，还要学会怎么找出来。Chrome DevTools的Memory面板是咱们的“照妖镜”。

6.1 拍下堆快照，对比前后变化

你打开一个页面，先点击Memory面板，选“Heap snapshot”，然后点一下“Take snapshot”拍第一张照片。接着你在页面里反复做一些操作，比如打开弹窗再关闭，或者切几个页面。然后再拍一张快照。在快照列表里选比较模式（All objects），你就能看到这两个时间点之间有哪些对象增加了。重点看“Constructor”那一列，如果发现大量的Component实例、HtmlElement实例，而且它们的数量在不断增长，那就说明它们没有被回收。

6.2 用Performance面板记录内存走势

在Performance面板里录制一小段时间，观察JS Heap的曲线。如果曲线是一条不断爬升的阶梯，每一阶段操作后都回不到原来的基线，那就说明有内存泄漏。这种可视化方式特别直观，适合在开发环境快速验证。

6.3 Angular DevTools 给你更多线索

Angular官方有专门的DevTools扩展，能看组件树和变更检测的消耗。你可以用它快速定位哪个组件被频繁创建、却一直没有销毁。还有一个技巧，在控制台执行ng.getComponent来找组件实例，从而确认某个元素是否还挂在组件树上。

可能有人会问，直接用window.performance.memory不就行了吗？确实可以使用：

// 在浏览器控制台执行这个命令，可以看看当前JavaScript内存占用情况
// 注意：这类API在部分浏览器中已经被移除了，Chrome目前还支持
console.log(performance.memory);

不过更推荐用DevTools的可视化面板，因为它的对比维度更丰富，而且能查看到具体的对象引用链。定位到可疑对象后，你可以右键点击，选择“Store as global variable”，然后在控制台里用Object的方法去分析它被谁引用了。

七、全面治理方案：让泄漏无处可逃

面对这么多泄漏点，咱们得有一套组合拳来对付。下面是我在实际项目里总结出来的一套“防漏大法”。

7.1 第一条军规：能用AsyncPipe就别手动订阅

前面提到过，AsyncPipe在组件销毁时会自动退订，这是最省心的方案。如果我们确实需要手动订阅，那就要统一走“退订管家”模式。

// 技术栈：Angular 12+ / TypeScript 4+
import { Component, OnDestroy, OnInit } from '@angular/core';
import { timer, Subject } from 'rxjs';
import { takeUntil } from 'rxjs/operators';

@Component({
  selector: 'app-notifier',
  template: `<div>通知消息：{{ message }}</div>`,
})
export class NotifierComponent implements OnInit, OnDestroy {
  message = '';

  // 这是一个 Subject，用来统一发送“我要停止订阅”的信号
  private destroy$ = new Subject<void>();

  ngOnInit(): void {
    // timer(0, 3000) 表示立即发一次，之后每3秒发一次
    timer(0, 3000)
      .pipe(
        // 当 destroy$ 发出信号后，自动断开所有订阅
        takeUntil(this.destroy$)
      )
      .subscribe((tick) => {
        this.message = `第 ${tick} 次通知`;
      });
  }

  ngOnDestroy(): void {
    // 在组件销毁时，一次性向所有订阅者发出“结束”信号
    this.destroy$.next();
    this.destroy$.complete();
  }
}

takeUntil(this.destroy$)这个操作符是官方推荐的模式。你只需要维护一个destroy$主题，在组件销毁时调用一次next()，所有挂着这个生命线的订阅都会自动退订。这样做的好处是，不管你有十个还是二十个订阅，只要每个订阅后面都加上takeUntil，最后只需要清理一个东西，简洁又稳妥。

7.2 第二条军规：DOM引用用完就扔

直接操作DOM的时候，心里要有一根弦：DOM对象不是普通数据，绝不能存放在长期存活的对象里。如果你要保存多个DOM的引用，试着把它们封装成“快照数据”，而不是DOM本身。比如你可以保存元素的位置坐标、宽高、文本内容。如果实在需要保存DOM，那就用一个WeakRef，这样垃圾回收器可以忽略这个引用，在需要时自动回收目标对象。但WeakRef是比较底层的特性，生产环境建议谨慎使用。

7.3 第三条军规：事件监听器成双成对

如果使用了原生addEventListener，务必在ngOnDestroy里调用removeEventListener。记住：同一个函数引用，同一个capture标志，才能正确移除。推荐把监听回调定义为类成员函数，而不要用匿名函数。

// 技术栈：Angular 12+ / TypeScript 4+
import { Component, OnDestroy, OnInit } from '@angular/core';

@Component({
  selector: 'app-window-tester',
  template: `<div>监听窗口大小变化</div>`,
})
export class WindowTesterComponent implements OnInit, OnDestroy {
  // 定义成成员函数，这样 add 和 remove 可以用同一个引用
  private onResize = (event: UIEvent): void => {
    console.log('窗口大小变了', window.innerWidth);
  };

  ngOnInit(): void {
    window.addEventListener('resize', this.onResize);
  }

  ngOnDestroy(): void {
    window.removeEventListener('resize', this.onResize);
  }
}

7.4 第四条军规：服务里只存数据，不存组件

在设计服务时，尽量不要把“会销毁的对象”传到全局单例服务里。如果必须在服务里维护一个列表，那就确保列表中的元素是纯数据模型，比如{ id: number, text: string }，而不是组件实例。一旦发现服务里保存了Component、HTMLElement、ElementRef，就要敲响警钟。

7.5 第五条军规：用禁用检查工具来兜底

依赖Angular的@angular/core中有个DestroyRef，这是Angular 16引入的一个好东西。它允许你用函数式的方式注册销毁回调，不需要非得实现OnDestroy接口。配合takeUntilDestroyed操作符，也可以省去手动定义destroy$的麻烦。

// 技术栈：Angular 16+ / TypeScript 5+
import { Component } from '@angular/core';
import { interval } from 'rxjs';
import { takeUntilDestroyed } from '@angular/core/rxjs-interop';

@Component({
  selector: 'app-ticker',
  template: `<div>时间戳：{{ currentTime }}</div>`,
})
export class TickerComponent {
  currentTime = 0;

  constructor() {
    // 在构造函数里开始订阅，并且指定自动销毁
    interval(1000)
      .pipe(
        // 这会在组件实例被销毁时自动退订
        takeUntilDestroyed()
      )
      .subscribe((value) => {
        this.currentTime = value;
      });
  }
}

只用一行takeUntilDestroyed()，连OnDestroy都不用实现，简洁又安全。不过要注意，takeUntilDestroyed必须写在“注入上下文”里，比如构造函数中，或者作为字段初始化器中。如果你在一个普通方法里调用，需要传入DestroyRef实例。

八、应用场景与技术优缺点

刚刚提到了很多细节，咱们再把这些内容放到实际应用场景里看看。

8.1 哪些场景最容易踩坑？

后台管理系统是重灾区。这种系统往往需要长时间开着，不停切换菜单、打开各种详情弹窗、报表、实时数据刷新。每一次新建组件再销毁，都是一次潜在的“垃圾”积累。第二种是数据可视化页面，图表库为了渲染性能会频繁操作DOM，很多时候还需要监听window的resize事件，如果忘了移除，就会导致图表对象泄露。第三种是实时推送场景，比如聊天应用、监控大屏，大量使用WebSocket或轮询，这些数据流订阅如果没有妥善管理，泄漏会非常快。

8.2 治理方案之间的优缺点对比

先说AsyncPipe。它的优点非常明显：代码简单，自动管理订阅生命周期，而且会主动触发变更检测。缺点则是不适合复杂的逻辑转换，如果订阅之后还需要做大量数据处理，你还是得在TS里手动订阅。

再看takeUntil模式。它能应对多种订阅的批量退订，灵活度高，能把业务逻辑全部留在TS里。缺点是必须在每个订阅的pipe末尾加上takeUntil，稍有不慎容易漏掉其中一个。另外，destroy$本身如果忘了清理，也会产生一个小泄漏，不过它只占用极少量内存，影响不大。

第三个是takeUntilDestroyed。它算是最新的“官方推荐”，代码最简洁，安全性高，也不需要额外定义destroy$。缺点是需要Angular 16及以上版本，如果你的项目还在用老版本，就没办法使用。

手动调unsubscribe是最笨但最直接的方法。优点是没有依赖，任何Angular版本都适用。缺点是容易忘记、容易漏，尤其在组件变大后，会让代码变得很臃肿。还是建议能用高阶封装就用高阶封装。

对于DOM引用，最理想的方案是不保存原始引用，只保存必要的数据。但有时我们需要连续操作一个DOM元素，比如拖拽插件，技术上很难完全不保存。这时候就要权衡：是定期清空，还是用WeakRef。WeakRef的优势是垃圾回收器可以在内存紧张时自动回收，但这样也可能导致你的对象在你的“期望使用周期”内被回收了，从而出现空引用错误，所以WeakRef只能用在非关键部分。

8.3 注意事项

第一，内存泄漏排查一定要在“发布模式”下进行。开发模式中Angular会保留很多调试数据，比如组件工厂和反射信息，这些会影响快照准确性。第二，在排查和修复过程中，建议每修复一个问题就拍一次快照验证，不要一次性改太多，否则很难定位到具体是哪一处修改起效了。第三，别忘了监听Router事件。如果你在某个页面订阅了Router.events，这个订阅是全局的，但如果你在组件里订阅了它，却忘了退订，那么你的组件也会被Router事件源引用。实际上，Angular的Router服务是一个全局单例，你订阅它之后，它会一直向订阅者推送事件，除非你调用unsubscribe。所以对于这种“全局数据流”，尤其要小心。

九、总结与心法

内存泄漏不是一天形成的，治理也不是一次就能万事大吉。要养成好习惯：优先用AsyncPipe，其次用takeUntil或takeUntilDestroyed；操作DOM时用数据代替引用；添加全局监听后记得移除；服务里永远不要存组件实例。还要学会用Chrome DevTools的堆快照和性能录制来定期“体检”。只要每次开发时带着这些意识，你的Angular应用哪怕连开一个月，也能保持丝般顺滑。

最后再啰嗦一句：别等到浏览器崩了才想起内存这回事。代码写出来容易，但交出代码之前，不妨问自己一句：“我有没有什么东西忘了清理？”如果回答不上来，那多半就是漏了。赶紧检查一下订阅和引用，别让一小块内存“赖”在页面里不走。