Flutter使用pushReplacement时如何等待孙路由pop获取返回值

原生pushReplacement的设计逻辑为：执行路由替换时，被移除的旧路由（对应Second页面）关联的、被父路由await的Future会立即以null完成，直接切断First到后续页面的等待链路。要在保留pushReplacement栈替换语义（Second彻底从栈中移除，不影响返回逻辑）的前提下，维持First对后续Third页面pop的等待，不需要重构现有跳转流程，按以下方案改造即可。

方案1：改造自定义路由的Completer绑定关系（最适配现有代码） #

目前项目已经使用了CustomMaterialPageRoute自定义路由，可基于Flutter Route类的底层实现逻辑调整路由替换时的Future绑定关系，完全不需要修改现有页面的业务跳转逻辑：

• 底层逻辑说明：每个Route实例内部都持有一个Completer对象，当Route被pop时会触发这个Completer完成，对应await该push操作的代码就会继续执行。原生pushReplacement会在替换时立即触发旧路由的Completer，我们只需要把这个Completer的引用转移到新的Third路由上即可。
• 核心改造代码示例：

  // 支持Completer转移的自定义路由
  class LinkedResultMaterialPageRoute<T> extends MaterialPageRoute<T> {
    /// 转移自旧路由的Completer，用于把完成事件透传给最初的await方
    Completer<T>? linkedCompleter;
  
    LinkedResultMaterialPageRoute({
      required super.builder,
      super.settings,
    });
  
    @override
    void didComplete(T? result) {
      // 优先触发关联的旧Completer，再走原路由的完成逻辑
      if (linkedCompleter != null) {
        linkedCompleter!.complete(result);
        linkedCompleter = null; // 避免重复complete抛出异常
      }
      super.didComplete(result);
    }
  }
  

  // 带链路保留的pushReplacement扩展方法
  extension NavigatorLinkResultX on NavigatorState {
    Future<T?> pushReplacementKeepChain<T extends Object?, TO extends Object?>(
      Widget Function(BuildContext context) builder, {
      RouteSettings? settings,
    }) async {
      final currentRoute = lastRoute!;
      // 取出当前旧路由绑定的Completer
      final oldCompleter = (currentRoute as dynamic).completer as Completer<T>?;
      
      // 构造新的支持链路转移的路由
      final newRoute = LinkedResultMaterialPageRoute<T>(
        builder: builder,
        settings: settings,
      );
      
      // 执行原生替换逻辑，把旧路由从栈中移除
      await pushReplacement(newRoute);
      // 把旧路由的Completer绑定到新路由上
      newRoute.linkedCompleter = oldCompleter;
      
      return null;
    }
  }
  

• 改造后的实际效果：
  • 路由栈状态和原生pushReplacement完全一致：Second被从栈中彻底移除，点击Third的返回键会直接回到First，不会残留Second的实例
  • First页面中原有的await Navigator.push(...)逻辑不会被立即触发，会等Third执行pop、把回传数据透传过来时，才会继续执行print("Back to first")，完全匹配预期流程

方案2：路由结果透传总线（适合多页面跨层传值的场景） #

如果不想改造底层路由实现，可以在应用层维护一个轻量的结果透传通道：

• 在全局状态中维护一个Function(dynamic result)? pendingResultCallback
• First页push跳Second时，把需要等pop完成执行的逻辑赋值给这个回调
• Second页用pushReplacement跳Third时，把这个回调透传给Third
• Third页pop时，调用绑定的回调，把回传值传给First
• 注意pop完成后要把全局的回调置空，避免内存泄漏

此前考虑的“控制pushReplacement的返回值，让它返回Third的引用再await”的方案存在设计缺陷：Second页对应的await链路和路由栈实际状态不匹配，因为栈中已经没有Second的实例，长期持有这个await引用容易导致内存泄漏、路由逻辑混乱，不如直接绑定Completer的方案自洽。

内容的提问来源于stack exchange，提问作者Daniel Porteous