WebSorceress一个老需求，换个平台就翻车了。公司这轮把React Native应用迁移到鸿蒙，我接手的是导航这一块。最典型的需求就是页面返回拦截：表单没保存时，用户点返回，要弹确认框。平时在StackNavigation里做这种事，靠的是beforeRemove事件；这个功能在Android上我写了几百遍，闭着眼都知道怎么挂BackHandler，但到了鸿蒙上，第一次真机测试就发现行为完全不对——从屏幕左边缘右滑返回，页面直接滑走，我挂在beforeRemove里的逻辑压根没等到弹窗。
后面几天我一直在翻react-native-harmony的源码和鸿蒙容器页的处理逻辑，把返回拦截整个链路重新捋了一遍。这篇文章就记录一下我在HarmonyOS NEXT上实现StackNavigation返回拦截的完整过程，包括为什么不能照搬Android方案、beforeRemove和usePreventRemove怎么选、系统侧滑手势拦不住时怎么兜底，以及几个容易被忽略的边界场景。如果你正在做RN鸿蒙化适配，或者准备把现有RN应用跑到鸿蒙设备上，这篇应该能帮你省不少排查时间。
1. 为什么鸿蒙上的返回拦截不能照搬Android方案
1.1 一次“看起来正常”的迁移，真机上却翻车了
先说背景。我们团队做的是跨端业务App，导航方案是React Navigation的StackNavigation，也就是@react-navigation/native-stack。返回拦截这个需求集中在几个页面：编辑草稿、填写表单、视频播放页，要求用户在离开前必须有确认动作。
Android上的做法很成熟，我一开始直接照搬：
tsx复制useEffect(() => {
const unsub = navigation.addListener('beforeRemove', (e) => {
if (!hasUnsaved) return;
e.preventDefault();
Alert.alert('提示', '当前内容尚未保存，确定离开吗？', [
{ text: '留下', style: 'cancel' },
{ text: '离开', onPress: () => navigation.dispatch(e.data.action) },
]);
});
return unsub;
}, [navigation, hasUnsaved]);
这段代码在Android模拟器、真机上都很稳。迁移到鸿蒙后，我第一时间在模拟器上跑了一遍，点击返回键、导航栏返回，弹窗都正常。当时我还松了口气，以为这块不用动。
结果真机一测就出问题了。HarmonyOS NEXT默认是手势导航，从屏幕左边缘右滑返回时，页面直接跟着手势滑走并退出了，压根没有触发beforeRemove。更诡异的是，某些场景下先触发了一次hardwareBackPress，然后又触发了beforeRemove，弹窗弹了两层，关掉一层后页面已经没了。
后来我翻react-native-harmony的issue和容器页源码才明白，鸿蒙的返回事件链路和Android不一样，不是一套逻辑能通吃的。
1.2 三个平台的返回事件差异
要想搞清楚鸿蒙上该怎么拦截，得先看三个平台的返回事件是怎么到RN层的。我整理了一个对比，方便你对照自己的场景：
| 维度 | Android | iOS | HarmonyOS NEXT |
|---|---|---|---|
| 主要返回方式 | 底部导航键、手势、键盘 | 系统边缘右滑 | 侧滑手势、底部横条上滑、键盘、悬浮球 |
| RN层主要API | BackHandler + beforeRemove | gestureEnabled + beforeRemove | BackHandler + beforeRemove（链路不同） |
| 侧滑手势能否被RN完全控制 | 部分可（预测性返回下有限制） | 系统手势优先，RN只能配合 | 系统手势优先，RN很难完全关闭 |
| 事件到达RN的时机 | 导航动作前可拦截 | 导航动作前可拦截 | 受原生容器页onBackPress影响，可能慢半拍 |
关键点在于最后一行。Android上React Navigation会把系统返回事件转成导航器的pop动作，然后走一遍完整的动作分发，所以beforeRemove一定能在这个分发过程中被触发，拦截自然有效。iOS上侧滑手势虽然由系统控制，但React Navigation通过gestureEnabled和事件回调也能把手势和导航动作绑在一起。
鸿蒙不一样。RN页面本身跑在一个原生容器页里，这个容器页是ArkUI的@Entry页面。用户侧滑返回时，系统先把这个事件交给ArkUI页面的返回生命周期，然后容器页再决定要不要把事件转发给RN。如果容器页直接执行了返回，RN里的导航器根本来不及反应。这就是为什么我模拟器上正常、真机上失效——模拟器的输入事件模拟和真机手势走的路径有细微差别。
所以，在鸿蒙上做返回拦截，第一原则是：不要只依赖JS层的beforeRemove，要前先确认你的react-native-harmony版本对应的容器页是怎么处理返回事件的。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 核心拦截机制：beforeRemove 与 usePreventRemove 的取舍
2.1 beforeRemove 到底拦的是什么
先把概念理清楚。beforeRemove不是“返回事件拦截器”，它是“路由移除前的事件钩子”。只要是StackNavigation里某个路由要被移除，不管是通过返回手势、返回按钮、navigation.goBack()、navigation.pop()，还是navigation.replace()，都会先触发beforeRemove。你在监听器里调用e.preventDefault()，这次移除动作就被取消，页面留在原地。
用白话讲：导航器已经把“我要干掉这个页面”的决议做好了，beforeRemove是最后的听证会。你不喊停，页面就没了；你喊停，导航器就收回决议。
那为什么确认弹窗里要用navigation.dispatch(e.data.action)，而不是重新调一次goBack()？
因为你手动调goBack()会再次触发beforeRemove，造成递归：弹窗确认后调用goBack()，又进监听器，再次preventDefault，然后弹窗又弹出来。而`e.data.a