这个问题应该出现很久了，之前的组件WillPopScope用的好好的，flutter做优化打算“软性”处理禁用返回手势，出了PopScope，这个组件也能处理在安卓设备上的左滑返回事件。但是iOS上面左滑返回手势禁用，一直无效。

当然之前一直在使用Navigator动态路由的方式的话是不影响的。

Navigator.push(context,MaterialPageRoute(
                        builder: (context) =>
                            FullScreenImagePage(images: [imagePath]),
                      ),
                    );

        但是对于静态路由和一些其他三方的路由(fluro,go_route,getx(这个在版本4.7.2中已修复))封装组件就会有影响。

那我们看下具体为什么会出现这种问题？

        首先我们看PopScope的内部实现是接口实现了PopEntry的一个ValueNotifier  canPopNotifier来控制内部的返回手势是否可用。

ModelRoute注册该事件，然后在这个抽象类中有统一的返回手势判断竞技场逻辑：

到此暂告一段落。

        上面我们说Navigator的动态路由方式没问题，那么就看下他的处理和其他的路由方式的差别：MaterialPageRoute的混入MaterialRouteTransitionMixin如下：

CupertinoPageRoute的混入CupertinoRouteTransitionMixin如下（我只截取了最有介绍的部分，想看的可以自己去文件里面看，路径我已经截出来了）：

                

        Flutter最近也一直在优化Cupertinao的组件库，上面的CupertinoPageRoute就是iOS的路由处理，可以看到差异很明显，页面page（这篇文章主要介绍page形式）形式的代码有自定义实现了手势_CupertinoBackGestureDetector，他通过参数方法enabledCallback来动态获取左滑手势是否有效。它的内部实现如下：

        可以看到enabledCallback的来源是route.popGestureEnabled,到此就是最终的位置了。通过断点可以看到，（前提是二级页面设置了PopScope的canPop为false）当Navigator的动态路由方式的时候，此处是false，左滑返回无效，一般其他的方式路由来的此处是true，左滑返回可以。

        由此而来，问题就出现在了route的popGestureEnabled上面，我们可以聚焦在此处，点击寻根，可以追溯到ModalRoute的popGestureEnabled（上面已截图，本文第三张图），问题就出在了第三个判断中的popDisposition==RoutePopDisposition.doNotPop上面，再往上看popDisposition的来源如下：

        问题的原因应当是此处路由在iOS设备中路由的转换导致canPopNotifier的变更出现的问题。

下面我们参考看下Get的PageRoute解决关键代码：

        可以看到GetX的最新调整将路由的手势带出来，判断处理 解决此次Flutter的iOS PopScope问题。（当然这只是表象比较明显的位置，具体详细大家有兴趣可以自行点进去再细致研究）