Angular CanDeactivate 路由守卫搭配 MatDialog 工作异常如何解决

• 原生confirm()的阻塞特性是核心对比基准：它是完全同步阻塞JS线程的调用，会把整个事件循环挂起，直到用户做出选择才返回结果，全程没有任何异步执行的间隙，自然不会出现提前渲染、组件叠加的问题。
• 你当前实现的Bug本质是打开MatDialog的执行时机不对：
  1. 导航触发走到CanDeactivate守卫时，你在confirmRouteChange方法里是**同步执行matDialog.open()**的。这个方法调用本身会立刻向DOM插入遮罩层、触发一次Angular全量变更检测。
  2. Angular Router为了做导航性能优化，在守卫检查阶段就已经提前把目标路由的组件准备好渲染到<router-outlet>里了，只是在守卫返回最终判定前，不会销毁旧组件、不会替换地址栏URL。
  3. 打开MatDialog触发的这次同步变更检测，会让Router跳过原本的等待逻辑，直接把提前准备好的目标组件渲染出来；但此时守卫还在等MatDialog的关闭事件返回结果，不会销毁旧组件，最终就出现了旧表单和目标页面上下叠在一起的效果。
• 你之前猜测的"Observable返回后触发导航"的方向是对的，但问题不在afterClosed()本身——这个Observable只是等对话框关闭的信号，完全符合守卫的返回要求；问题是同步打开对话框的动作，在Router还没进入完全等待状态时就触发了变更检测，诱导Router提前完成了目标组件的渲染。

核心要做的是把MatDialog的打开动作，从守卫的同步执行栈里挪到Router完全进入导航挂起状态后再执行，避免同步打开对话框触发提前渲染。
具体做法是把原本直接返回afterClosed()的逻辑，包裹成一个自定义Observable：把打开对话框的动作放到Observable的订阅回调里。订阅动作的触发时机是Router拿到你返回的Observable之后，这时候Router已经完全把导航流程暂停、进入等待状态，不会再触发提前预渲染的逻辑。

修改后的confirmRouteChange方法：

import { Observable } from 'rxjs';
import { MatDialogRef } from '@angular/material/dialog';
import { Subscription } from 'rxjs';

confirmRouteChange() {
  // 表单无脏数据直接放行
  if (!this.isDirty) return new Observable<boolean>(sub => sub.next(true));

  // 自定义Observable，等Router真正订阅时再打开对话框
  return new Observable<boolean>((subscriber) => {
    let dialogRef: MatDialogRef<AlertModalComponent>;
    let dialogSub: Subscription;

    // 此时Router已经完全进入导航等待状态，打开对话框不会触发提前渲染
    dialogRef = this.matDialog.open(AlertModalComponent, {
      data: {
        msg: 'Your changes have not been saved. If you leave this page, your changes will be lost.',
        title: 'Changes have not been saved',
        class: 'save-changes'
      },
      // 额外配置：禁止用户点遮罩、按ESC关闭对话框，避免误操作导致未拦截导航
      disableClose: true
    });

    // 把对话框的用户选择结果传递给守卫
    dialogSub = dialogRef.afterClosed().subscribe((navAllowed: boolean | undefined) => {
      // 对话框如果没返回明确值，默认拦截导航，避免误放行
      subscriber.next(navAllowed ?? false);
      subscriber.complete();
    });

    // 资源清理：如果Observable被取消订阅（比如导航被其他流程打断），自动关闭弹窗、清理订阅，避免内存泄漏和遗留弹窗
    return () => {
      dialogSub?.unsubscribe();
      if (dialogRef) dialogRef.close();
    };
  });
}

• 不要直接在同步执行栈里调用matDialog.open()然后把afterClosed()直接返回，一定会触发刚才说的时序问题。
• 一定要加上disableClose: true配置，否则用户点遮罩层、按ESC键会直接关闭对话框，此时afterClosed()返回的是undefined，如果没做空值处理，会被守卫当成true直接放行导航，拦截逻辑就失效了。
• 记得加资源清理的teardown逻辑，避免用户在弹窗打开时重复触发导航，导致多个弹窗叠在一起、产生内存泄漏。

内容的提问来源于stack exchange，提问作者Joseph Santana