最近团队在忙一件事把商城App的React Native端往OpenHarmony生态上迁移前端技术栈选了React Native for OpenHarmony后面统一叫RNOH。整个项目里支付成功这个功能看着不起眼真做起来却是最容易翻车的一环。用户付款后的那几秒涉及支付渠道回调、本地订单状态、后端验签、页面跳转、防重复点击……任何一个环节没串好轻则页面状态不对重则用户重复下单。这篇就把我们从架构选型到支付成功实现的关键步骤和踩坑记录完整写下来给同样在RNOH上做电商类App的朋友一个参考。先说结论支付成功功能的实现难点根本不在画一个成功的交互页面而在于把支付回调、订单状态机、路由栈、后端验签这些跨端链路理顺。RNOH本身就是从RN生态长出来的所以大部分业务代码能保留但涉及原生能力的部分比如支付、推送、扫码必须用鸿蒙原生模块补齐。下面按我们的实际推进顺序展开。1. 为什么是RNOH商城项目技术选型复盘1.1 摆在面前的几条路我们商城App原本是Android/iOS双端RN代码覆盖面比较广商品列表、购物车、订单、个人中心都是RN实现的。现在要覆盖使用鸿蒙生态设备的用户当时摆在面前的路大概有三条ArkUI重写用ArkTS把商城全部重写一遍系统体验和性能确实最好但等于整个商城再养一套代码双份开发双份维护业务排期直接爆炸。WebView套壳把现成H5商城包进鸿蒙WebView里交付最快但关键页面结算、支付结果体验明显打折而且我们前端团队早已放弃维护H5版本这条路等于开倒车。RNOH渐进迁移保留RN业务逻辑用RNOH把React Native运行时搬到OpenHarmony上对强原生依赖的模块支付、分享、扫码、推送做单独适配。我们最终选了第三条。技术选型拼的不只是单点性能更是团队存量和交付节奏。RNOH能最大化复用现有JS代码支付这类能力用原生模块单独补齐收益成本比相对均衡。尤其商城这种页面多、逻辑重的App用RNOH渐进迁移比推倒重来现实得多。1.2 RN新老架构对比选型时怎么用项目讨论期间正好赶上社区里聊RN新老架构对比这里多提一句。老架构是Bridge桥接JS和原生之间通过异步消息队列通信批量调用还行高频方法调用延迟明显新架构是Fabric TurboModule JSI通过JSI直连JavaScript引擎方法调用接近同步类型推导也更好。RNOH在适配时同样面对新老架构的取舍。老架构Bridge模式下鸿蒙侧原生模块要靠全局注册注入经常有模块未按时注入导致JS侧拿到undefined的情况新架构TurboModule通过代码生成做接口绑定稳定性和调用效率都更好。我们最后直接锁定支持新架构的RNOH版本后面支付模块能稳定跑起来这个选型前提很关键。如果你只在RNOH上写纯页面不碰原生能力新旧架构感受不出来。一旦做支付这种桥接操作就必须分清新老架构的差异否则排查问题时会绕很大一圈。1.3 性能与包体积的实测感受先放两个我们实测过的大数。在OpenHarmony真机上支持新架构的RNOH版本冷启动到首页可交互比我们预想的快基本在1.2秒到1.8秒区间取决于设备性能包体积增加约14MB到18MB对商城类App来说在可接受范围内。页面渲染方面列表页滚动和详情页图片加载表现不错暂时没遇到明显的掉帧问题。支付成功页这种轻交互页面更是没有压力。反而是一些RN老代码里大量使用inline style和嵌套View层级在OpenHarmony上会拖慢首次布局优化思路和RN老项目完全一致用StyleSheet.create定义样式、拍平无意义的嵌套层级。2. 支付成功这个功能本质是订单状态机2.1 别把支付成功当页面当状态不少开发第一次做支付会理解成用户付款成功跳转一个成功页就完了。实际做下来你会发现支付成功不是一个页面而是订单状态机里的一次状态迁移页面只是迁移完成后给用户看到的UI反馈。我建议在动手前先把订单状态字段列清楚。以我们商城为例状态含义PENDING已创建订单待支付PAYING已调起支付渠道支付处理中PAID支付成功FAILED支付失败或支付取消CLOSED订单关闭超时未支付RN端可以维护一份本地状态副本但不要让它成为权威数据源。前端是状态的表现层后端才是状态的所有者。我们在实际开发里把这份状态机同时落到了后端和前端store里字段名、枚举值完全对齐防止前后端各叫各的导致联调时无谓扯皮。2.2 调起支付的原生桥接NativeModule这样暴露支付SDK在鸿蒙侧以原生能力存在RNOH的JS侧无法直接调用需要我们先封装一个原生模块。以我们项目为例鸿蒙侧暴露了一个PayModuleJS侧的调用代码如下// payModule.ts import { NativeModules } from react-native; const { RNPayModule } NativeModules; export enum PayChannel { WeChat wechat, Alipay alipay, } export interface StartPayParams { orderId: string; amountInCents: number; // 单位分 channel: PayChannel; } export interface PayResult { code: PayResultCode; message: string; channelTradeNo?: string; // 支付渠道单号 } export enum PayResultCode { PaySuccess PAY_SUCCESS, PayFail PAY_FAIL, PayCancel PAY_CANCEL, } export function startPay(params: StartPayParams): PromisePayResult { return RNPayModule.startPay(params); }原生侧在鸿蒙上用ArkTS写一个继承TurboModule的类注册进来。这里只贴核心方法签名// PayModule.ets NativeModule export class PayModule extends TurboModule { JSCall startPay(params: Recordstring, Object): PromisePayResult { // 调起支付宝/微信在鸿蒙侧的SDK // 支付完成后resolve或reject } }注意两个细节第一金额一律用分作为单位传Int不做浮点运算避免精度问题第二不同支付渠道的返回结构不一样原生模块层统一成PayResultJS侧就不用关心渠道差异了。2.3 回调链路设计从渠道到UI支付SDK回调给鸿蒙原生层之后原生层再把结果传回JS。我们用了两条通道Promise通道startPay方法本身返回Promise正常场景直接resolve支付结果。事件通道原生主动向JS侧发PAY_RESULT事件防止Promise链路在某些异常场景下丢失。事件监听在RN侧这样挂// payEvents.ts import { NativeEventEmitter, NativeModules } from react-native; const { RNPayModule } NativeModules; const payEmitter new NativeEventEmitter(RNPayModule); export function subscribePayResult(callback: (result: PayResult) void) { const subscription payEmitter.addListener(PAY_RESULT, callback); return () subscription.remove(); }两条通道在业务层做了一次去重同一个订单支付结果只取先到的那个。实际线上排查问题时事件通道抢在Promise前面是常有的事两路都保留心里更踏实。3. 支付成功页面的实现细节3.1 三种结果三种UI分支支付回调不可能只有成功。我们页面里同时处理三种结果成功、失败、取消。成功页展示对勾动画、订单金额、商品概括和操作按钮失败页展示失败原因、当前订单状态并提供重新支付的入口取消页比失败页更克制只提示支付已取消按钮只剩返回订单。这里容易被忽略的是结果页是临时页面用户可能通过订单列表、通知栏、支付回跳等多条路径进入所以页面初始化时必须先从后端拉一次订单详情再用后端数据校正UI不能单纯相信本地拿到的回调结果。3.2 倒计时、防重复点击和路由栈清理成功页最基础的交互是展示成功后自动跳转。我们做了3秒倒计时给用户留出反应时间倒计时结束后自动回订单列表。倒计时由Hook实现// useCountdown.ts import { useEffect, useRef, useState } from react; export function useCountdown(seconds: number, onFinished?: () void) { const [remain, setRemain] useState(seconds); const timerRef useRefReturnTypetypeof setInterval(); useEffect(() { timerRef.current setInterval(() { setRemain((prev) { if (prev 1) { clearInterval(timerRef.current); onFinished?.(); return 0; } return prev - 1; }); }, 1000); return () clearInterval(timerRef.current); }, []); return remain; }页面上的两个按钮查看订单和返回首页都必须做防重复点击处理。点击一次后进入loading状态并禁用按钮防止用户手抖连点导致路由被重复push多次。更重要的是路由栈清理从支付成功页返回首页要用navigation.reset而不是goBack否则用户按返回键时会重新回到支付页甚至可能再次触发支付属于必须踩过才算知道的坑。3.3 动画与原生体验平衡支付成功页少不了成功动画。我们第一版想上Lottie后来发现RNOH环境下Lottie需要鸿蒙原生扩展支持版本匹配成本不低。权衡后直接用RN内置Animated实现了一个对勾动画逻辑简单也够用// SuccessCheckAnimation.tsx import { useEffect, useRef } from react; import { Animated, Easing, View, StyleSheet } from react-native; export function SuccessCheckAnimation() { const scale useRef(new Animated.Value(0)).current; const opacity useRef(new Animated.Value(0)).current; useEffect(() { Animated.parallel([ Animated.timing(opacity, { toValue: 1, duration: 200, useNativeDriver: true, }), Animated.spring(scale, { toValue: 1, friction: 4, useNativeDriver: true, }), ]).start(); }, []); return ( Animated.View style{[ styles.circle, { opacity, transform: [{ scale }], }, ]} / ); }动画交互上有一条原则不要因为动画阻塞核心操作。用户在动画还没播完时就点击查看订单必须立刻响应不能等动画结束了才跳转。4. 与后端协同验签、幂等、金额一致性4.1 客户端永远不要相信回调里的钱支付结果到了客户端只能当提示不能当结论。真正的状态仲裁必须由后端做。我们前端拿到支付成功回调后立刻调后端的确认订单接口大致逻辑如下前端携带订单号、支付渠道单号、支付结果请求POST /orders/{orderId}/pay/confirm。后端用自己配置的支付渠道公钥验签确认这笔支付在渠道侧真实存在。渠道侧同步返回该订单的实付金额后端拿它和订单应付金额比对。全部通过后后端把订单状态置为PAID同时返回给前端最终的订单详情。支付宝走RSA2验签微信走APIv3的HMAC-SHA256验签这些校验只能在服务端做。客户端能做的最多是把异常状态上报给监控系统别把客户端当成可信来源。4.2 重复通知与幂等处理支付渠道的异步通知不是通知一次就完事的典型情况下会主动重试多次直到业务方返回成功应答。如果后端没有做幂等同一笔订单被通知两次就可能出现重复入账、重复发货的严重事故。幂等键我们用的是渠道单号 订单号。后端收到一条支付结果时先查这个幂等键是否已处理过处理过直接返回已确认后续逻辑不再执行。把幂等逻辑放在数据库的unique约束和事务里而不是靠应用层if判断才能扛住并发场景。4.3 金额一致性校验金额校验是最容易漏的一环。恶意用户可以通过篡改客户端参数把支付金额从实际应付100元改成0.01元传给支付渠道支付渠道可能直接按这个金额收钱。虽然这是渠道侧要防的风险但业务后端也必须自保。我们在后端下单时就把订单金额冻结支付确认时强制校验渠道返回实付金额 订单应付金额对不上的自动进入风控复核同时推送告警。客户端能做的配合是所有金额展示都来自后端字段前端一律不做自行计算避免页面显示金额与实付金额不一致引发客诉。4.4 轮询补偿回调丢了怎么办即使有支付渠道回调用户支付成功但客户端没收到通知的情况依然常见。比如App在支付过程中被系统杀掉或者网络切换导致回调延迟。我们做了一个标准兜底方案进入订单详情页时下拉刷新实时拉后端状态监听AppStateApp从后台回前台时自动刷新当前订单详情订单列表页对PAYING状态的订单显示支付确认中并做15秒一次轻量轮询。这套轮询不重不卡做一个setInterval包在AppState的active状态里切换后台时清掉回前台再起避免空转耗电。5. 真机避坑记录我们走过的弯路5.1 遇到NativeModules返回undefined第一版联调时最恶心的一个现象是刚启动App马上点支付偶尔会报RNPayModule is undefinedApp重启后又不报。定位下来是RNOH桥接模块没随JS bundle加载完成就注册到位由于TurboModule初始化时序和路由跳转竞争导致模块查找失败。解决办法有两个一是适配层把支付模块的引用缓存到顶层用getter做延迟解析而不是每次调用时现取二是业务层在调起支付前做一个模块就绪检查未就绪时拉取一次模块再发起。两个都加上之后这个概率性问题基本消失。5.2 返回栈里的僵尸支付页有一次测试反馈用户支付成功后点首页再返回居然又回到支付成功页页面上还能再点一次支付。根因是跳首页时用了navigation.navigate而不是路由重置旧页面一直挂在栈里成了僵尸页。修复方式是在跳转前重置栈结构// 从支付成功页回首页 navigation.reset({ index: 0, routes: [{ name: Home }], });订单列表页和购物车页同理凡是支付成功后可达的业务页面都要把所有支付流程页面从栈里清出去。这条我们是在测试阶段靠退出重进复现逼出来的真到线上就是客诉了。5.3 构建依赖解析失败有段时间OpenHarmony侧构建频繁报依赖解析失败日志里类似could not determine the dependencies of task :app:compiledebug...看来看去是RNOH版本与鸿蒙SDK版本不匹配导致的原生模块编译找不到符号。排查思路和RN老项目一致先锁定RNOH版本对应的鸿蒙SDK API等级再检查第三方原生扩展的版本兼容矩阵最后把hvigor缓存目录清掉重编。我们清缓存重编三次确认是缓存问题后给CI脚本加了一步定时清缓存任务再没出现过。5.4 字体、布局和适配上抖过的小坑支付成功页有大量金额、时间、订单号的展示。在OpenHarmony真机上部分华为系统字体的数字宽度和Android不一致导致金额换行订单号显示不全。我们统一用fontVariant: [tabular-nums]加上固定lineHeight解决。另一个小细节是安全区适配。鸿蒙设备有不少是曲面屏和挖孔屏支付成功页底部按钮如果直接怼到屏底会被系统手势条遮挡。RNOH的SafeAreaView要确认用的是兼容鸿蒙的实现不要用默认空实现。5.5 关于测试阶段的抓包支付功能的联调阶段真机抓包也是绕不开的事。需要说明的是支付接口涉及真实资金和风控不要随便对线上支付接口抓包容易触发渠道风控甚至被封。我们的做法是联调环境全部走支付渠道沙箱支付请求打到后端测试环境再给测试机装上信任证书抓HTTPS明文。生产环境只靠日志系统打点定位问题客户端不做任何抓包。写在最后的实际体会支付成功功能单独看是一个结果页真正做起来牵扯到状态机、路由栈、原生桥接、服务端验签和幂等像一个微型的分布式事务。我们在RNOH上把这套跑通之后把支付结果页、倒计时Hook、回调去重逻辑抽成了独立组件和工具函数后续其他业务页面要展示支付结果直接复用不再重复踩坑。根据我个人经验如果你也开始做RNOH商城项目优先级建议是先把订单状态机和后端确认接口定死再实现支付调用桥接最后才画支付成功页。顺序反了多半会在联调阶段来回返工。