在React Native跨端这条路上，OpenHarmony是一个绕不开的新平台。最近把公司的核心流程页迁移到鸿蒙生态上，最让我记忆犹新的不是首页性能优化，也不是复杂的动画，而是一个看似人畜无害的Modal确认取消弹窗。这东西在Android/iOS上闭眼就能写，到了OpenHarmony上却让我踩了一整天的坑——先是启动白屏，再是弹窗背景突然渲染异常，最后还碰上弹窗在部分设备上直接不显示。这篇文章就把我在React Native + OpenHarmony上实现Modal确认取消弹窗的全过程记录下来，包括方案选型、完整代码、关键配置，以及启动白屏、画面渲染异常、设备兼容性这几个高频问题的排查思路。无论你是正在评估RNOH的可行性，还是已经接入但被弹窗类组件卡住的开发者，这篇应该都能帮上忙。
1. 整体设计思路与方案选型
1.1 React Native适配OpenHarmony的原理
先花两分钟把底层逻辑说清楚，不然你在排查问题时会很被动。React Native本身并不直接认识OpenHarmony，它默认支持的是Android、iOS、Web这些平台。RNOH（React Native OpenHarmony）是OpenHarmony SIG组主导的适配项目，做的事情是把RN的JavaScript引擎层（Hermes/JSC）、渲染管线（Fabric/Paper）和原生组件逐一映射到OpenHarmony的ArkUI框架上。
你可以把它理解成一座桥：RN侧写的JS/TS代码，最终通过Node-API与ArkTS层通信，再由ArkUI的组件完成真实渲染。也就是说，我们在RN里写一个View，RNOH会把它翻译成ArkUI的Stack/Column/Row等布局组件去绘制；我们调用一个Modal，RNOH也会去找ArkUI里对应的弹窗能力来撑起这个Modal。这座桥搭得好不好，直接决定了弹窗能不能按预期盖在最顶层、遮罩能不能半透明、动画能不能播放。
为什么要用RN而不是ArkTS原生开发？理由很简单：复用。大部分团队已经把业务逻辑沉淀在RN代码里了，如果能直接跑到鸿蒙设备上，成本比亚要从零写一遍ArkTS低得多。但这个“低”是有前提的——你得接受RNOH目前还不像Android/iOS那样成熟，很多细节需要自己踩坑修补。另外要澄清一个概念：RNOH只能跑在OpenHarmony的标准系统上，像LiteOS-M这类轻量设备（常见于智能家电、IoT传感器）根本带不动RN的运行时，别在兼容性测评时把两者混为一谈。
1.2 Modal的两条实现路线，为什么我推荐这一条
先说结论：在RNOH上做确认取消弹窗，有两条路线，我推荐优先使用系统Modal组件，同时准备一个自绘弹窗作为兜底方案。
路线A：直接使用RN的Modal组件。RNOH对Modal已经做了适配，当你在JS侧渲染Modal时，RNOH会把它映射到ArkUI的原生弹窗窗口上。这种方案的好处是层级绝对够高，能盖过状态栏、底部导航，遮罩半透明效果也是系统级的，和Android/iOS的表现最接近。
路线B：自绘弹窗，也就是不引入Modal组件，用View + position: 'absolute' + zIndex在页面内部模拟一个弹窗。这个方案的好处是纯JS实现，不依赖RNOH对Modal的适配程度，在Modal组件有bug（比如transparent背景失效、动画异常）时可以作为兜底。坏处也很明显：它只能覆盖在页面布局内，盖不住状态栏和系统导航，遇到页面跳转时层级会乱，而且没法真正脱离页面容器去渲染。
既然路线A有原生适配，我一开始就直接选了它。后面在排查“弹窗不显示”和“遮罩变黑底”时，也验证了它和自绘弹窗的边界：系统Modal在RNOH上属于原生弹窗窗口，一旦ArkUI侧没有正确挂载，表现就是整个PopUp窗口压根不出现；而自绘弹窗虽然丑一点，但至少能看到View在布局里。所以我的方案是：主流程用系统Modal，遇到RNOH版本带不动Modal的场景时，快速切换自绘弹窗顶上。
2. 环境准备与工程接入
2.1 版本选型：RNOH的版本矩阵
RNOH这个项目迭代速度很快，版本之间差异巨大，选错版本等于给自己埋雷。我实测下来的稳定组合是：
| 组件 | 版本 | 说明 |
|---|---|---|
| OpenHarmony SDK | 5.0.0（API 12） | 系统能力覆盖较全，RNOH适配最好 |
| DevEco Studio | 5.0.0及以上 | 太老的版本不支持新的ArkTS语法 |
| React Native | 0.72.5 | RNOH在0.72系列上最稳 |
| @react-native-oh/react-native | 0.72.x对应版本 | RN的鸿蒙适配版JS侧 |
| @react-native-oh/react-native-harmony | 0.72.x对应版本 | 包含ArkTS与C++原生侧实现 |
| Node.js | 18及以上 | Metro打包需要 |
| CMake | 3.7及以上 | DevEco会用到C++编译 |
为什么是0.72系列而不是更新的0.73、0.74或0.75？我在项目早期试过0.73以上版本，虽然Fabric新架构的路子是对的，但RNOH上很多原生模块还停留在Paper架构的适配程度，新架构虽然能开但稳定性不够。0.72是比较均衡的选择：社区用户量大，踩坑记录多，遇到问题搜索一下就有答案，而且适配OpenHarmony的har包版本齐全。别人选新版本是尝鲜，我们做业务是要稳定。
2.2 工程接入：从build-profile到Metro
工程接入的核心思路是：在标准RN工程基础上，额外配置鸿蒙侧的入口和依赖。具体步骤我按顺序列一下。
第一步，在package.json里把react-native替换为鸿蒙适配版：
{ "dependencies": { "react": "18.2.0", "react-native": "npm:@react-native-oh/react-native@^0.72.5", "@react-native-oh/react-native-harmony": "0.72.x" } }第二步，在鸿蒙工程entry模块的build-profile.json5里，把RNOH的har包加入依赖：
{ "apiType": "stageMode", "buildOption": { "arkOptions": { "runtimeOnly": { "packages": [ "src/main/cpp/CMakeLists.txt" ] } } }, "dependencies": { "@react-native-oh/react-native-harmony": "file:../harmony/react-native-harmony.har" } }第三步，配置Metro。如果只是跑开发调试，npm start启动Metro后，真机或模拟器会从8081端口拉JS bundle。这里要特别注意：开发模式下启动白屏，九成是Metro没连上，后面会专门讲排查思路。
第四步，在ArkTS入口里创建RNInstance并加载bundle。这里以standard系统为例，主要代码大致是初始化RNOHCoreContext、注册组件和TurboModule，然后加载metro server或release bundle。代码比较长就不全贴了，建议直接照RNOH官方模板工程改。
2.3 发布模式下的bundle配置
开发调试和线上发布是两套不一样的流程。开发时Metro实时供包，发布时需要先把JS bundle打进鸿蒙应用的rawfile目录。
通常的做法是在package.json里加一个构建脚本：
{ "scripts": { "bundle-harmony": "react-native bundle --platform harmony --dev false --entry-file index.js --bundle-output ./harmony/entry/src/main/resources/rawfile/bundle.harmony.js --assets-dest ./harmony/entry/src/main/resources/rawfile" } }然后执行npm run bundle-harmony，把生成的bundle拷贝到rawfile。这里有个坑：bundle文件名必须和ArkTS侧加载时传入的名字一致，很多白屏问题就是名字对不上导致的。我在release包里的加载代码大概是new RNBundleLoader(getContext().filesDir + '/bundle.harmony.js')这样的逻辑，只要路径和文件名统一，问题就不大。
3. Modal确认取消弹窗的完整实现
3.1 核心组件：确认取消弹窗的代码拆解
下面是我在实际项目里用到的完整实现，直接在RNOH 0.72 + API 12上跑通过。我先把代码放出来，再逐段解释为什么这么写。
// ConfirmDialog.jsx import React from 'react'; import { Modal, View, Text, TouchableOpacity, StyleSheet, ActivityIndicator, } from 'react-native'; const ConfirmDialog = ({ visible, title = '提示', message, confirmText = '确定', cancelText = '取消', confirmColor = '#1677ff', loading = false, onConfirm, onCancel, }) => { return ( <Modal visible={visible} transparent={true} animationType="fade" onRequestClose={onCancel}> <View style={styles.overlay}> <View style={styles.alertBox}> <Text style={styles.title}>{title}</Text> {message ? <Text style={styles.message}>{message}</Text> : null} <View style={styles.buttonRow}> <TouchableOpacity style={[styles.button, styles.cancelButton]} onPress={onCancel} disabled={loading}> <Text style={styles.cancelText}>{cancelText}</Text> </TouchableOpacity> <TouchableOpacity style={[styles.button, styles.confirmButton]} onPress={onConfirm} disabled={loading}> {loading ? ( <ActivityIndicator size="small" color="#fff" /> ) : ( <Text style={styles.confirmText}>{confirmText}</Text> )} </TouchableOpacity> </View> </View> </View> </Modal> ); }; const styles = StyleSheet.create({ overlay: { flex: 1, backgroundColor: 'rgba(0, 0, 0, 0.45)', justifyContent: 'center', alignItems: 'center', }, alertBox: { width: 280, backgroundColor: '#ffffff', borderRadius: 16, paddingTop: 24, paddingHorizontal: 20, overflow: 'hidden', }, title: { fontSize: 17, fontWeight: '600', color: '#1a1a1a', textAlign: 'center', }, message: { marginTop: 10, fontSize: 15, lineHeight: 22, color: '#666666', textAlign: 'center', }, buttonRow: { flexDirection: 'row', marginTop: 22, borderTopWidth: StyleSheet.hairlineWidth, borderTopColor: '#e5e5e5', }, button: { flex: 1, height: 50, justifyContent: 'center', alignItems: 'center', }, cancelButton: { borderRightWidth: StyleSheet.hairlineWidth, borderRightColor: '#e5e5e5', }, cancelText: { fontSize: 16, color: '#666666', }, confirmButton: { backgroundColor: 'transparent', }, confirmText: { fontSize: 16, color: '#1677ff', fontWeight: '500', }, }); export default ConfirmDialog;几个容易被忽略的关键点我单独拎出来讲。
第一，transparent={true}必须显式声明。RNOH的Modal默认行为和Android一致，如果不写transparent，弹窗会以不透明全屏窗口的身份出现，背景直接变白，遮罩就废了。
第二，animationType我推荐用fade。实测在RNOH上fade最稳，slide在部分设备上有动画缺失或者抖动的问题，尤其是在API 10/11的老版本上，slide的表现只能用惨不忍睹来形容。
第三，onRequestClose不要省略。虽然OpenHarmony上未必每个设备都有物理返回键，但在支持手势返回的设备上，用户从屏幕边缘滑动返回时，如果没有这个回调，弹窗会直接关掉但遮罩还挂在页面上，视觉上很诡异。我建议统一绑到onCancel上。
3.2 页面调用与状态回传
组件本身是纯受控组件，页面里用起来也很直接：
// DemoPage.jsx import React, { useState } from 'react'; import { View, Text, TouchableOpacity, Alert } from 'react-native'; import ConfirmDialog from './ConfirmDialog'; const DemoPage = () => { const [dialogVisible, setDialogVisible] = useState(false); const [submitting, setSubmitting] = useState(false); const handleDelete = () => { setDialogVisible(true); }; const handleConfirm = async () => { if (submitting) return; setSubmitting(true); try { // 模拟异步删除操作 await new Promise((resolve) => setTimeout(resolve, 1500)); setDialogVisible(false); // 删除成功的业务提示 } catch (error) { // 错误提示 } finally { setSubmitting(false); } }; const handleCancel = () => { setDialogVisible(false); }; return ( <View style={{ flex: 1, justifyContent: 'center', alignItems: 'center' }}> <TouchableOpacity onPress={handleDelete}> <Text>删除这条记录</Text> </TouchableOpacity> <ConfirmDialog visible={dialogVisible} title="确认删除" message="删除后不可恢复，确定要继续吗？" confirmText="删除" cancelText="再想想" loading={submitting} onConfirm={handleConfirm} onCancel={handleCancel} /> </View> ); }; export default DemoPage;这里我要重点提醒一个异步状态的问题。很多人在确认按钮里做异步请求时，没处理好submitting状态，导致用户连续点两下“确定”，弹窗被触发两次删除操作。上面代码里我在handleConfirm开头就加了一个if (submitting) return的拦截，这是最基本的防重复。
另外一个坑是：当loading为true时，两个按钮都要disabled，不能只disabled确认按钮。否则用户在loading过程中点取消，虽然弹窗被关了，但异步请求还在飞，等请求回来了setDialogVisible(false)又触发一次渲染，React Native控制台会给你一块红色警告，RNOH上表现得更明显。我实测下来，取消按钮在loading期间禁用掉，体验最稳。
3.3 函数式封装：像Alert.alert一样调用
如果只是单页面用一次弹窗，上面的受控组件写法已经够了。但一个App里到处都要确认弹窗，每次都要维护visible状态和回调，写起来很累。我在项目里又做了一层Promise封装，让业务代码弹窗像调用Alert.alert一样简单。
核心思路是维护一个全局的单例弹窗组件，通过Promise把确认/取消的结果抛给调用方：
// dialogApi.js import React, { useState, useImperativeHandle, forwardRef } from 'react'; import ConfirmDialog from './ConfirmDialog'; let dialogRef = null; export const dialogApi = { show(options) { return dialogRef.show(options); }, hide() { dialogRef.hide(); }, }; export const DialogHolder = forwardRef((props, ref) => { const [state, setState] = useState({ visible: false, options: {}, }); let resolveRef = null; useImperativeHandle(ref, () => ({ show(options) { return new Promise((resolve) => { resolveRef = resolve; setState({ visible: true, options }); }); }, hide() { setState((prev) => ({ ...prev, visible: false })); }, })); const { visible, options } = state; return ( <ConfirmDialog visible={visible} {...options} onConfirm={() => { resolveRef && resolveRef(true); setState((prev) => ({ ...prev, visible: false })); }} onCancel={() => { resolveRef && resolveRef(false); setState((prev) => ({ ...prev, visible: false })); }} /> ); });然后在页面根部挂一个DialogHolder，注册ref：
// App.jsx <DialogHolder ref={(ref) => { dialogRef = ref; }} />业务侧调用就非常清爽了：
const confirmed = await dialogApi.show({ title: '确认删除', message: '删除后不可恢复，确定要继续吗？', confirmText: '删除', loading: false, }); if (confirmed) { // 执行删除逻辑 }这个封装有一个需要特别注意的点：DialogHolder本身也是RN组件，它必须挂在App根部，不能挂在某个被卸载的页面里，否则弹窗会不翼而飞。另外，如果调用方把弹窗的显示放在了一个被cleanup的页面里，Promise的resolve会失效，所以我在封装里加了resolveRef的存活检查，避免拿到一个永远不返回的Promise。
4. 弹窗样式与交互细节适配
4.1 背景遮罩、圆角与动画
弹窗好不好看，全看遮罩、圆角和动画这几个细节。
遮罩我使用的是rgba(0, 0, 0, 0.45)，这个透明度在深色和浅色页面上都能压得住，不会出现页面文字透过遮罩还隐约可辨的情况。有些设计稿喜欢用0.5更暗一些，但太暗会让弹窗视觉上很“闷”。Android原生AlertDialog的遮罩大约在0.4到0.5之间，0.45这个值是安全的选择。
圆角方面，Android的Material风格弹窗通常是28dp大圆角，iOS的UIAlertController是14dp左右。我折中了16dp，在鸿蒙的ArkUI渲染下看起来比较协调。这里有个真实踩过的坑：如果弹窗的alertBox没有设置overflow: 'hidden'，当按钮行的背景色或边框被圆角裁切时，四个角会露出方形的毛边。加上overflow hidden之后，按钮行会被正确裁切。
动画方面，RNOH的Modal在fade动画下表现正常，但我遇到过两种异常：一是部分设备上动画执行完会出现一整帧的闪烁，二是slide动画在API 11以下的机型上位移距离明显偏大。这类问题追到RNOH源码，其实是动画参数在ArkUI侧做了百分比换算，但兼容性没做完整。稳妥的做法是把动画时间拉长一点，比如0.25秒，视觉上就不容易察觉异常。如果业务对动画要求高，可以考虑关闭动画，用自绘弹窗自己写Animated。
4.2 按钮布局、防重复点击与生命周期
按钮布局用的是最经典的左右双按钮结构，flexDirection: 'row' + flex: 1，两个按钮各占一半宽度。中间的分割线用的是StyleSheet.hairlineWidth，这个值在RNOH里会被正确归一化为1物理像素，不会像直接写1那样在部分高分屏上变成2像素甚至3像素的粗线。
按钮高度我固定为50，这个尺寸对触控友好，也在视觉上不会让弹窗显得太矮。确认按钮我建议放右边，这是Android/iOS的习惯约定，用户已经形成了“右边是积极操作”的肌肉记忆，别反着放。
防重复点击除了在异步请求里拦截，还有一个办法是给确认按钮加一个短时间的节流：
const lastPressRef = useRef(0); const handleConfirmPress = () => { const now = Date.now(); if (now - lastPressRef.current < 1000) return; lastPressRef.current = now; onConfirm(); };这个1秒节流虽然粗暴，但在RNOH上非常有效，因为ArkUI侧的事件回传有时候会有一次事件被派发多次的问题，节流能把这个脏数据过滤掉。
生命周期这块要特别留意。Modal的visible从true变成false时，RNOH会异步地去关闭原生弹窗窗口，不是同步完成的。如果在调用方把弹窗所在页面一起卸载了，就可能出现弹窗窗口虽然关了，但ArkUI侧还残留一个透明layer，视觉上表现为页面白了一块。解决的办法是给Modal的onDismiss（如果RNOH支持）或onRequestClose里做状态清理，不要依赖Visible变化的瞬间来销毁内容。这个逻辑在Android上也有类似约定，只是RNOH上更明显一点。
5. 启动白屏、渲染异常这些坑，我是这么排查的
5.1 启动白屏的三大根源与对策
启动白屏是RNOH被吐槽最多的问题。很多人一上来就认为是鸿蒙系统适配不行，其实大部分是工程配置问题。以我实测经验，白屏主要来自三个源头。
第一个源头：Metro没连上。开发模式下，RN应用启动后第一件事就是从Metro下载JS bundle。如果Metro没启动、端口被占用、或者真机和电脑不在同一个局域网，bundle加载失败，页面自然一片白。排查方法很直接：看Metro控制台有没有收到请求，没有请求就是网络不通；有请求但报错就是bundle编译问题。另外注意，OpenHarmony模拟器在部分网络环境下访问宿主机IP会受限，建议把Metro监听地址改成0.0.0.0，确保设备能访问到。
第二个源头：Release包里bundle文件缺失或路径不对。这个我在2.3节提过，发布模式必须先把JS bundle打包进rawfile，而且名字要和ArkTS侧加载时一致。曾经有一次我改了bundle文件名，但entry里的加载路径没同步更新，结果安装包在启动时一直找不到bundle，白屏卡了十分钟，最后用hdc shell翻应用沙箱文件才发现问题。建议在加载代码里加一个bundle存在性判断，提前打日志。
第三个源头：首帧性能问题。RNOH启动时要把Hermes引擎初始化、加载JS bundle、执行业务初始化代码，再加上ArkUI侧创建RNRootView，整个过程在低端设备上可能要好几秒。这个阶段页面确实是白的。优化手段包括：在原生侧增加启动图、把JS侧复杂的初始化逻辑延后、关闭不必要的渲染调试日志。RNOH提供了enableDebug开关和内置性能面板，打开之后能看到具体的初始化耗时区间，定位瓶颈很方便。
5.2 画面渲染异常的常见表现与修复
画面渲染异常这个概念比较大，我在迁移过程中遇到过的具体问题有这么几类，每一类都有对应的解法。
第一类是边框线过粗。在RN里写的borderWidth: 1，在部分鸿蒙设备上渲染出来像是2甚至3像素。原因是RNOH在长度单位换算上把RN的dp和ArkUI的vp做了统一，但部分版本没有对borderWidth做归一化处理。如果你升级RNOH版本后还有这个问题，可以先确认要不要在build-profile里开启像素归一化配置。我在0.72上实测是有归一化的，但老设备上偶尔还是会有偏差。
第二类是圆角失效或半透明失效。具体表现是弹窗背景变成纯白不透明box，遮罩完全失效。这个问题追到根上，是RNOH的Modal在transparent属性传递上和老版本ArkUI的弹窗API存在兼容性缺口。遇到这个情况，优先升级RNOH到对应RN版本的最新patch，如果还不行，就把弹窗切到自绘方案，用绝对定位的View去模拟遮罩。虽然层级略低，但至少遮罩效果可控。
第三类是字体、图片不显示。RNOH为了控制安装包体积，默认没有内置完整的字体解码能力，同时网络图片需要额外的图片加载器。如果页面里用了JS侧的Text但字体不生效，检查一下entry模块里有没有挂载对应的字体资源；图片白屏则要确认网络图片加载模块有没有被正确注册。这些细节虽然和Modal没有直接关系，但弹窗内容里一旦出现图片或特殊字体，问题就会暴露出来。
我整理了一个速查表，方便你按图索骥：
| 现象 | 可能原因 | 排查手段 | 解决方案 |
|---|---|---|---|
| 启动白屏（开发模式） | Metro未连上/网络不通 | 看Metro日志、ping端口 | 监听0.0.0.0、切换网络 |
| 启动白屏（发布模式） | bundle缺失/路径不对 | 检查rawfile、hdc沙箱日志 | 统一bundle名、加存在性判断 |
| 弹窗背景纯白不透明 | transparent属性传递失败 | 升级RNOH、换自绘弹窗 | 使用系统Modal升级patch |
| 遮罩黑底不透光 | 遮罩rgba解析失败 | 检查RNOH版本 | 改用自绘弹窗 |
| 边框线过粗 | 归一化配置未生效 | 对比多台真机 | 检查归一化开关 |
| 圆角有毛边 | overflow未隐藏 | 增加overflow:hidden | 样式修复 |
| 网络图片不显示 | 图片加载器未注册 | 看原生日志 | 注册网络图片解码器 |
6. 设备兼容性总结与踩坑记录
6.1 不同系统版本的兼容性表现
RNOH在不同OpenHarmony版本上的兼容性差异巨大，这是做设备适配时必须心里有数的事。我按自己测过的系统版本做个总结。
HarmonyOS NEXT（API 12及以上）是目前最顺的环境。系统Modal的transparent、动画、onRequestClose表现都和预期一致，RNOH的高版本har包也主要针对这个SDK编译，基本不用做太多兼容处理。
OpenHarmony 4.1（API 10/11）可以跑RNOH，但Modal的动画和遮罩效果会有一定缩减。我实测fade动画在这上面没有API 12那么平滑，偶发掉帧。如果产品要求不高，还是可以接受的。
OpenHarmony 3.2（API 9）这一代对RNOH的支持就比较勉强了。系统Modal在黑屏时容易卡住，transparent背景在部分设备上失效。如果你必须支持这个系统版本，老实说Modal体验很难做好，建议多做几轮真机验证。
至于LiteOS-M这类轻量系统设备，它连RNOH的运行条件都不具备，直接放弃就好。这里就不是弹窗没适配的问题，而是整个RN运行时都跑不起来。
6.2 其他值得注意的坑
兼容性之外，还有几个我在实际项目中踩过的小坑，顺便一起记下来。
第一个是返回键的处理。OpenHarmony支持手势返回后，用户在弹窗内从屏幕边缘右滑，可能会触发onRequestClose。如果你的业务里这一步是“确认取消”，结果弹窗被手势关掉，用户以为取消了，但实际业务操作还挂在那里，体验很糟。解决方式是配合页面的根返回事件一起做状态管理，保证弹窗内手势和物理返回走同一套逻辑。
第二个是第三方弹窗库兼容性。react-native-modal这类纯JS实现的弹窗库，在RNOH上有一定概率能用，因为它的底层还是走Modal或View定位。但如果用了需要原生依赖的能力，比如BlurView模糊背景、Portal提供者，基本就凉了。建议在RNOH上尽量少依赖原生三方库，弹窗这种高频组件，自己写一个足够用。
第三个是调试技巧。RNOH提供了setNativeLoggingEnabled之类的开关，打开后能看到比JS控制台更详尽的ArkTI层日志。排查Modal类原生组件问题时，这个开关的价值很大。另外我用hdc（鸿蒙的调试命令行工具）比较多，看日志、推文件、查沙箱都很方便，强烈建议熟练掌握。
写在最后的经验
把这篇文章写下来，是希望后来者少走一些弯路。以我自己实际操作的体会来说，RNOH的坑大多是“能用但需要验证”的适配级问题，而Modal确认取消弹窗恰好是最容易暴露适配问题的一类场景。如果你正打算把RN业务迁移到OpenHarmony，我的建议是：先把系统Modal这类基础设施跑通，再考虑业务上的花活；遇到白屏先查Metro和bundle，遇到渲染异常先确认版本和归一化配置，遇到弹窗不显示就直接切换自绘方案兜底。最后再分享一个小技巧：在RNOH上做弹窗组件，样式层面尽量别依赖太多平台差异，保持在系统默认能力范围内实现，踩坑概率会小很多。祝你的鸿蒙落地之路顺利。
