Ionic + Capacitor 项目中，Android 和 iOS 的返回行为有什么区别

看起来相同的“返回”，背后不是同一套机制

在 Ionic + Capacitor 应用中，Android 返回键、Android 侧滑返回和 iOS 左边缘返回，给用户的感受都像是在“回到上一层”。但从实现上看，它们并不经过同一条链路。

Android 端可以通过 Ionic 的 ionBackButton 事件注册处理器，并用优先级决定谁先消费这次返回。iOS 左边缘返回则主要由 ion-router-outlet 的 swipe handler 控制，本质上仍然是在操作路由栈。

这一区别在普通路由页面中不明显，一旦页面上出现不属于路由的弹窗，问题就暴露出来了。

项目里的弹窗大致有三类：

前两类在视觉上像新的页面层级，但没有进入 Vue Router。系统只知道当前路由仍然可以返回，不知道用户眼前还有一个应该先关闭的弹窗。

Android 端的处理可以直接围绕 ionBackButton 建立分层规则。

我先在 App.vue 中注册全局处理器，优先检查 popupStore 的全屏弹窗栈。如果有弹窗，就关闭栈顶弹窗并消费事件；如果没有，就把处理权交给下一层。

页面内弹窗则通过公共的 useBackButtonDismiss hook 接入。页面只需要声明“当前是否有弹窗打开”和“如何关闭”，监听的注册、注销和事件传递由 hook 统一处理。

最终返回顺序可以概括为：

全局全屏弹窗
  -> 页面内局部弹窗
    -> Vue / Ionic 路由返回

这个顺序比在每个页面里单独判断更可靠。最初只处理聊天页的角色设置弹窗时，很快就发现同页反馈弹窗、分类筛选抽屉、资料编辑弹窗和 OC 编辑弹窗都有相同风险。把机制收敛到 hook 后，各页面只保留业务状态，不再重复编写系统事件代码。

处理全局弹窗时也不能简单地“只要有弹窗就关闭”。加载态、不可中断流程或自带关闭协议的弹窗需要单独识别，否则统一返回会破坏原有状态机。

iOS 左边缘返回不是 Android ionBackButton 的另一个名字。页面内弹窗没有进入路由栈，也很难像 Android 那样在同一个事件管线里先消费手势。

这时更稳的方案是：弹窗打开期间临时禁用底层路由的侧滑返回，弹窗关闭后再恢复。

项目中新增了 useSwipeBackLock，通过 Ionic 配置控制：

window.Ionic?.config.set('swipeBackEnabled', false)

它并不是把弹窗伪装成路由，而是明确告诉路由出口：当前存在更高层级的交互，不要响应底层页面返回。

如果只用布尔值控制，会出现多弹窗状态互相覆盖的问题：弹窗 A 和弹窗 B 同时需要锁定侧滑，A 先关闭时把配置恢复了，但 B 仍然处于打开状态。

因此 hook 使用 Set 保存锁来源：

这个设计看似比一个布尔值复杂，但它解决的是全局配置和局部组件生命周期之间的所有权问题。

在创建角色标签弹窗中，我还遇到了底部内容被固定确认按钮遮挡的问题。它与返回机制不是同一个 bug，但都与“视觉层级和真实布局层级不一致”有关。

弹窗内部真正滚动的是 .stacks，底部 .footer 使用固定定位。如果滚动容器没有为 footer 和 iOS 安全区预留空间，用户看到按钮盖住内容，但浏览器已经认为列表滚到底了。

最终用同一个 --footer-height 同步 footer 高度和滚动区域底部留白：

padding-bottom: calc(var(--footer-height) + env(safe-area-inset-bottom));

固定元素覆盖在内容上方时，视觉遮挡不会自动转化成文档流中的空间。这个判断和弹窗返回问题有一个共同点：不能只根据用户看到的层级推断浏览器或框架理解的层级。

这次实现最后形成了两套平台策略：

两端的用户目标一致，都是“先处理当前弹窗，不要误退出底层页面”，但技术入口不同。强行复用同一段代码，反而会掩盖系统行为的差异。

我分别验证了这些场景：

处理混合应用的返回行为时，我现在会先画清四个层次：系统输入、Ionic 事件、路由栈和页面内状态。只有路由栈真正变化时，才能依赖默认返回；视觉上覆盖页面的组件，需要自己声明它在返回顺序中的位置。

跨平台适配也不应该追求“代码看起来完全一样”。更重要的是保持交互语义一致，并让每个平台使用自己稳定、可维护的能力完成它。