Flutter 3.16.1中PopScope报'!_debugLocked'断言错误的解决咨询

问题根源 #

你的错误核心是PopScope与WillPopScope的工作逻辑完全不同：

• WillPopScope是在系统执行pop前回调，通过返回false直接阻止默认pop，再执行自定义导航，不会和系统导航流程冲突。
• PopScope的onPopInvoked是在系统启动pop流程（或尝试启动）后触发的，此时导航器处于锁定状态（_debugLocked为true），如果此时再调用Navigator.pop或push类方法，就会触发断言错误。

你之前的代码里，不管hasProfilePicUpdated状态如何，都在onPopInvoked里手动调用导航方法，同时默认canPop: true会让系统自动执行一次pop，相当于同时触发两次导航操作，直接导致锁冲突。

修正方案 #

核心思路：用canPop控制是否允许系统执行默认pop，仅在需要自定义导航时阻止系统默认行为，避免重复触发导航操作。

修正后的代码 #

PopScope(
  // 仅当不需要自定义导航时，允许系统执行默认pop
  canPop: !hasProfilePicUpdated,
  onPopInvoked: (didPop) async {
    // didPop为true表示系统已完成pop操作，无需再处理
    if (didPop) return;

    // 需自定义导航时，执行跳转逻辑
    if (hasProfilePicUpdated) {
      Navigator.pushNamedAndRemoveUntil(
        context,
        Routes.dashboard,
        (route) => false,
        arguments: DashboardArgumentModel(
          onboardingState: dashboardArgumentModel.onboardingState,
        ).toMap(),
      );
    }
  },
  child: Scaffold(
    // 你的页面内容
  ),
)

代码说明 #

1. canPop的设置：

   • 当hasProfilePicUpdated为true时，canPop: false，阻止系统执行默认pop，避免和自定义导航冲突。
   • 当hasProfilePicUpdated为false时，canPop: true，让系统自动处理返回逻辑，无需手动调用Navigator.pop。

2. onPopInvoked的逻辑：

   • 参数didPop用于判断系统是否已完成pop操作，为true时直接返回，避免重复操作。
   • 仅在需要自定义导航时执行跳转逻辑，此时canPop: false，系统不会执行默认pop，不会触发锁冲突。

为什么之前的尝试无效 #

你用WidgetsBinding.instance.addPostFrameCallback或Future.delayed延迟执行导航操作，本质上没解决重复触发导航的问题——系统已经在执行默认pop，延迟后的操作还是会和未完成的导航流程冲突，所以断言错误依然存在。

内容的提问来源于stack exchange，提问作者Ayan Dasgupta