一次 Android 返回手势问题的完整排查过程

问题并不只属于路由

在移动端 WebView 应用里，很多弹窗在视觉上很像一个新页面：它覆盖当前内容、有自己的关闭按钮，用户也自然会认为系统返回键能够关闭它。

但从实现上看，弹窗不一定进入路由栈。项目里既有由全局状态控制的弹窗，也有直接写在业务页面中的组件弹窗。它们显示在页面上，却不会因为路由返回而自动消失。

这就产生了一个典型问题：弹窗打开时触发 Android 返回，底层页面先退出了，弹窗却没有按照用户预期关闭。继续为每个页面单独补一个返回监听，只会让相同逻辑散落到更多组件里。

先分清三种状态

排查这类问题时，我先把“返回”拆成三个层次：

1. 系统事件：Android 返回键或返回手势发出返回请求。
2. 界面覆盖层：当前是否有弹窗、预览层或其他应该优先关闭的内容。
3. 路由页面：只有没有覆盖层需要处理时，才应该退出当前页面。

问题最后落在返回优先级上：这次事件应该先由谁消费？

如果顺序反过来，路由先执行返回，弹窗的关闭逻辑再正确也已经太晚。可靠的处理顺序应该是：

当前可见覆盖层 → 当前页面的特殊状态 → 路由返回 → 应用级兜底

统一覆盖层的关闭协议

项目中的弹窗来源不同，关闭方式也不相同。全局弹窗通常由 store 状态控制，页面内弹窗则由局部响应式变量控制。为了避免在返回处理器里识别每一个具体弹窗，我把共同部分抽象成一个轻量协议：

• 当前覆盖层是否打开；
• 如果打开，怎样关闭；
• 关闭后是否已经消费本次返回事件。

页面只需要提供自己的状态和关闭方法，公共逻辑负责监听系统返回、判断优先级和清理监听。这样新增弹窗时不必复制一整套平台代码，也减少了页面销毁后监听器残留的风险。

没有必要把所有弹窗改成同一个组件。它们只需要在系统返回这件事上遵守同一种行为约定。

Android 和 iOS 不能强行共用同一入口

Android 的问题主要来自系统返回事件；iOS 更常见的是边缘侧滑。两者都表现为“用户想离开当前界面”，但触发机制和页面反馈并不一样。

弹窗打开时，iOS 侧滑可能直接退出底层页面，因此需要在覆盖层存在期间临时锁定页面侧滑，关闭后再恢复。这个策略和 Android 的返回事件消费不能简单写成同一个分支，否则容易出现一端正常、另一端交互僵硬的问题。

最终保留的是统一的优先级模型，而不是完全相同的平台实现。

验证不能只看弹窗能否关闭

完成修改后，我重点检查了这些路径：

• 弹窗打开时返回，只关闭弹窗，不退出底层页面；
• 连续打开和关闭弹窗，不会重复注册返回监听；
• 页面离开后，旧监听器不会继续响应；
• 没有弹窗时，原有页面返回逻辑保持不变；
• iOS 覆盖层打开时不会误触底层页面侧滑；
• Android 与 iOS 的处理方式独立，但最终交互预期一致。

这次排查留下的判断

混合应用中的返回问题，通常不是一个按钮或一个事件的问题，而是界面状态、路由状态和原生平台事件之间的协调问题。

以后再遇到类似现象，我会先确认：当前看到的内容到底是不是路由页面，状态由谁持有，返回事件先经过哪里，以及页面销毁时谁负责清理。先把这四件事说清楚，再写处理逻辑，通常比不断添加条件判断更可靠。