CYDYSY1. 为什么用 React Native 做商城，还要折腾鸿蒙适配
这两年移动端选型有个很有意思的现象：新项目要么直接上纯原生，要么咬咬牙上跨端框架，但很少有人认真算过一笔账。我做电商类 App 也有六七年了，从早期的 Hybrid 到后来的 React Native，中间踩过的坑不少，但说实话，如果再让我选一次，商城这种业务密集、页面繁多、迭代速度快的项目，React Native 依然是我会优先考虑的方案，哪怕它有不少老毛病。
商城应用和普通工具类 App 有本质区别。一个稍微像样的商城，至少包含首页信息流、商品列表、搜索筛选、商品详情、购物车、订单流程、个人中心、售后维权这些模块，再加上秒杀、拼团、优惠券、积分商城这类营销玩法，页面数量轻松超过五十个。如果全用原生开发，双端加起来工作量直接翻倍，而且后续每加一个促销活动就要两端同步排期，版本节奏根本跟不上运营的需求。React Native 的价值在商城场景下体现得特别明显：一套 TypeScript 代码跑两端，UI 组件和业务逻辑基本复用，热更新能绕开应用商店审核快速上线活动页，这对电商来说就是生产力。
但要聊鸿蒙适配，情况就没那么简单了。鸿蒙生态这两年的发展速度确实超出很多人的预期，从最初的兼容 Android 到如今纯血 HarmonyOS 的推进，越来越多的国产应用开始把鸿蒙版本提上日程。React Native 社区对鸿蒙的支持，目前还处于“能用但不够完善”的阶段。这意味着你在 Android 和 iOS 上跑得好好的 RN 代码，真要跑到鸿蒙设备上，还是得做一轮专门的适配工作，而不是装个包就能完事。这个过程涉及的坑，比如启动白屏、原生模块桥接失效、第三方库不兼容、har 封装问题，每一个都可能卡住团队好几天。
这篇文章就围绕我最近做的一个 React Native 商城项目，把我踩过的坑、验证过的方案、以及鸿蒙适配过程中摸索出来的经验整理出来。重点会放在架构设计、关键模块实现、跨端适配的完整链路这几个部分。无论是刚入门的 RN 新手，还是已经在做商城但还没碰过鸿蒙的团队，这篇文章应该都能给你省下不少调研时间。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 商城应用的核心链路：从首页信息流到购物车结算
2.1 信息流架构与列表性能，这是第一个分水岭
商城的首页和商品列表是性能压力最大的地方。用户一进来看到的是几十个商品的瀑布流，往下滑的过程里还要不断加载更多。如果列表渲染卡顿，用户大概率在 3 秒内就退出了。
React Native 里做长列表，基本绕不开 FlatList。但很多人用 FlatList 只是简单地设个 data 和 renderItem，等数据量上来才发现问题：滑动掉帧、内存上涨、图片加载白屏。我这边第一个建议是，商城这种高频刷新的大列表，永远不要直接塞一个大的 data 数组进去，而是要做数据切分和渲染节流。
我采用的是分层加载策略：首屏只渲染第一屏可见的 10~12 个商品，用 FlatList 的 initialNumToRender 控制，windowSize 根据机型调整，maxToRenderPerBatch 每次渲染不超过 5 个。同时把图片组件的加载逻辑单独封装，用 react-native-fast-image 做三级缓存，避免每次都从服务端拉图。这一套组合拳打下来，首屏加载时间能压缩 40% 左右，iOS 和 Android 上的滚动都能稳定在 60 帧。
说个容易忽视的细节：商品图片的尺寸必须统一裁剪后再返回给前端。我见过很多团队直接把运营上传的原始图片丢给客户端，一张图三四兆，列表一屏十几个商品，内存直接爆掉。正确做法是服务端按两套尺寸出图，列表用小图，详情页用大图，图片服务器自己做缩放裁剪。前端只管按需取图，别在客户端做压缩，性能差且不可控。
2.2 分类导航和筛选组件，别用 WebView 偷懒
分类页面是电商的骨架。左侧一级分类、右侧二级分类列表、顶部搜索栏加筛选 Tags，这个交互在原生里是标配，但很多 RN 项目喜欢偷懒用 WebView 包一个 H5 页面。如果你的商城只是展示商品，那 H5 确实够用；但一旦涉及复杂的筛选条件（价格区间、品牌、规格属性、排序方式），WebView 的体验会让你想骂人——每次筛选都要和原生通信，状态同步繁琐，而且滑动不跟手，用户感知非常明显。
我这边分类页和筛选面板都用纯 RN 实现。筛选面板这里有一点要注意：不要用绝对定位加透明遮罩来硬憋动画，而是要用 RN 自带的 Modal 组件配合 Animated 做滑入滑出。Modal 能帮你处理 Android 上的返回键事件和遮罩点击事件，不然你还要自己去监听 BackHandler，很容易出 bug。
筛选条件的数据结构要设计得扁平一些，后端返回的筛选项建议是一个数组，每个元素包含 key、label、options，前端渲染成多组可折叠的标签集合。选中的条件用一个 Map 维护，key 是筛选组的唯一标识，value 是当前选中的值。这比用普通对象方便得多，因为 Map 的 set 和 get 在频繁更新时更高效，而且天然支持遍历。
2.3 商品详情页的页面栈管理，也别小看
详情页是商城转化率最关键的一环，也是页面栈最复杂的一环。从详情页可以跳转店铺、跳转客服、唤起购物车、进入支付结算，每一层都可能再返回到前面多个页面。React Native 的导航库我推荐用 react-navigation 的 native-stack，性能比 JS stack 好不少。
但这里有个坑：原生栈每次压栈都会保留上一个页面的原生视图，这会导致内存持续增加。尤其从首页进详情页，再进店铺页，再进商品详情页，三四个页面下来，内存能涨到原来的两倍。我的做法是限制页面栈深度，比如只在导航器里保留最近五个页面，超过的把最底层的页面用 navigation.popToTop 直接清掉。对于电商的浏览路径来说，用户很少会深度回退超过五层，这种取舍是值得的。
另一个和详情页相关的细节是商品规格选择弹窗。很多商城 App 的规格弹窗是覆盖在详情页之上的，但 React Native 的 Modal 在 Android 上有个历史遗留问题：弹窗打开时，背后的页面可能不会触发 onBlur，导致焦点管理混乱。实测下来比较稳的方案是，规格弹窗不用 Modal，而是用一个全屏覆盖的绝对定位 View 组件，配合透明度和 translateY 的动画做显隐，视觉上完全能达到原生弹窗的效果，而且焦点管理完全可控。
3. 购物车、订单支付与商家模块的实战细节
3.1 购物车状态管理：用 Zustand 还是 Redux Toolkit
购物车是电商数据流最复杂的地方，因为它涉及多商品校验、选中状态管理、数量变更、优惠计算，而且每个变更都会影响底部结算栏的金额。状态管理方案我一直用 Zustand，而不是 Redux。不是说 Redux 不行，而是购物车这种状态更新频繁、逻辑相对集中的场景，Zustand 的写法更轻，心智负担更小。
购物车 store 的设计上，核心是维护一个 Map<skuId, CartItem> 结构。CartItem 包含 skuId、spuId、title、price、image、quantity、selected、stock 这些字段。选中状态的变化、数量的增减、删除操作，全部走 store 的 action。结算金额用 selector 做派生数据，这样只有真正影响金额的状态变化才会触发结算栏重渲染。
这里有个经验值得分享：网络请求千万不要直接写在 store 的 action 里面。购物车页面进入时先拉一次购物车列表，但用户点击增减数量时，UI 先做本地乐观更新，把请求结果返回后再纠偏。如果每一个操作都等接口回来再更新 UI，用户在弱网环境下会感觉到明显的延迟。乐观更新出现接口报错时，再回滚到之前的状态并弹 toast 提示。这种模式在电商场景里几乎是必需的。
3.2 订单流程与支付模块，回调链路要理清楚
订单提交到支付成功，这个链路是商城可靠性要求最高的地方，没有之一。我见过太多团队在这块出问题：用户付了款，App 里还显示待支付，客服被骂到崩溃。核心原因是支付结果的通知机制没处理好。
iOS 和 Android 的支付回调有本质区别。iOS 的 IAP 是以服务端回调为准，客户端只负责发起和展示结果；Android 的微信支付和支付宝支付，既有客户端回调也有服务端回调，但两个回调到达的先后顺序不确定。所以客户端的 UI 展示不能直接以支付回调的结果为准，而是要在收到回调后，再次请求后端确认订单状态，用服务端的数据作为最终展示依据。
具体到代码层面，我封装了一个 PaymentManager，负责调起支付、监听回调、轮询订单状态三个职责。支付回调进来后不直接跳转，而是先调一个 confirmOrderStatus 接口，拿到明确的支付成功状态后再跳转订单详情页。轮询超时设置 10 秒，超过三次仍未确认就不再进行 UI 跳转，提示用户稍后在订单列表查看。这种方案虽然多了一次网络请求，但极大减少了因为回调时序导致的订单状态错乱。
3.3 商家入驻与店铺页面，别忽略 WebView 和原生的混合使用
商城 App 里的商家模块，在很多企业里其实是 PGC 内容和中台数据的展示层。店铺首页、商家介绍、资质证照这些页面，通常用 H5 承载更灵活，因为商家会频繁编辑店铺装修，原生页面跟不上内容更新的节奏。
但店铺页面里有一块必须用原生：店铺的商品列表。这个列表需要保证和主端商品列表一致的滑动性能，并且支持下拉刷新、上拉加载、商品排序切换。H5 页面嵌在 WebView 里做这些，性能会明显打折扣，尤其是在低端 Android 机上。我这里采用的混合方案是：WebView 承载店铺头部装修区和底部品牌故事区，店铺商品列表用原生 FlatList 单独渲染。WebView 与原生列表融合的方式是用页面内嵌滚动容器 + 跨端消息通信，WebView 滚动到底部时发消息让原生加载更多商品。
这种混合方案的关键点是事件桥接。需要在 WebView 和原生侧各封装一层事件总线，保证两个容器之间的滚动事件、加载状态、数据传值都能同步。我建议在 WebView 侧用 window.postMessage 做消息发送，原生侧通过 onMessage 接收；反过来原生侧需要通知 WebView 时，用 injectJavaScript 执行一段 JS 代码。这段桥接代码要写在公共 SDK 里，不要散落在各个业务页面中。
4. 鸿蒙跨端适配：完整的改造链路与实战避坑
4.1 鸿蒙适配到底改什么，先弄清边界
提到鸿蒙适配，很多团队的焦虑来自于“不知道要动多少代码”。其实从 React Native 工程的角度看，鸿蒙适配分三条线：JS 业务层代码基本不用动、JS 依赖的第三方 RN 库需要逐项验证、原生侧需要新增鸿蒙工程配置。搞清楚这个边界，你就不会一上来就想着重写整个项目。
我维护的这套商城工程，业务代码约九成是可以直接跑在鸿蒙环境上的，真正要花精力的是原生模块这层。React Native 的鸿蒙化，社区目前有一套比较成熟的思路：使用 OpenHarmony 的 RN 适配层，把 RN 的 JS 运行时和鸿蒙的 ArkUI 组件做映射。这套方案已经在不少商业项目里跑通了，但前提是你的 RN 版本不能太老。我建议至少使用 RN 0.72 以上，最好在 0.74 及以上，因为较新版本对 ArkTS 的支持更完整，性能表现也更接近 Android 端。
鸿蒙工程这边，目录结构和 Android/iOS 完全不同，它根目录是 entry 模块，下面有 src/main/ets 目录存放 ArkTS 代码，还有 module.json5 配置文件。RN 的鸿蒙适配包安装后，会在 entry 模块里生成 RNAbility、RNPageAbility 这些入口文件，你的 RN 页面就通过这些 Ability 加载。这块如果团队里没人搞过鸿蒙原生开发，稍微有点陡，但照着官方模板走一遍基本能跑起来。
4.2 原生模块桥接：从 Java/OC 到 ArkTS 的迁移
商城这种大型应用，几乎不可能只用纯 JS 实现所有功能，我这边涉及的原生模块包括：支付、分享、推送、地图定位、图片选择器、统计分析 SDK、WebSocket 长连接等。这些模块在 Android 上是 Java/Kotlin 写的 bridge，iOS 上是 Objective-C/Swift 写的 bridge，到了鸿蒙就必须用 ArkTS 重新写一遍桥接层。
迁移工作量最大的是支付模块。微信支付、支付宝支付在鸿蒙生态里都有对应的 SDK，但接口设计和 Android 版的差异很大。我踩过最深的坑是：鸿蒙的微信支付 SDK 回调路径和 Android 不一样，它需要一个 WXEntryActivity 来处理回调，但这个 Activity 要放在 entry 模块的特殊路径下，路径错了微信直接不回传结果，而且没有任何报错日志。
支付桥接类名和方法名的映射也有讲究。RN 侧调用原生模块时，走的还是 NativeModules 那一套机制，鸿蒙侧需要用 @TurboModule 装饰器来注册模块。这里的 getName() 返回的字符串必须和 JS 侧使用的模块名完全一致，大小写都不能错。我建议把所有桥接模块的注册名单独用一个常量文件维护，两边引用，避免手写出错。
4.3 鸿蒙适配中的性能雷区：启动白屏与列表渲染
热搜词里那个“react native 启动白屏”是真实存在的，而且在鸿蒙上更容易触发。我排查下来的根因有三个：一是所以 JS Bundle 的加载时机，二是首屏组件渲染的阻塞，三是原生侧 Activity 的启动模式。
第一个问题，RN 在鸿蒙上加载 JS Bundle 走的是本地文件读取加 JSBundle 解析，比 Android 慢不少。我处理的方案是把 Bundle 文件内置到鸿蒙工程里，不走网络下载，同时启用 Hermes 引擎的预编译字节码，启动时会显著缩短解析时间。这里有个参数要留意，hermesBytecode 在鸿蒙上要打开 serializedCodeSetting 才能生效。
第二个问题是首屏渲染。商城首页有几个原生模块是启动阶段必须初始化的，比如推送 SDK、登录状态检查、定位服务。这些初始化如果全部放在首页组件 useEffect 里，会阻塞 JS 线程导致白屏时间拉长。我把这些初始化统一挪到了一个 StartupTask 管理器里，按优先级分两批执行：第一批是白屏前必须完成的，只有登录态检查；其余全部放到首屏渲染完成后的空闲时间执行。改造后首屏时间从原来的 3.8 秒降到了 2.1 秒，这个优化对用户留存的影响是实打实的。
第三个问题是列表渲染的卡顿。鸿蒙的 ArkUI 组件和 React Native 的 Virtual DOM 映射本身有开销，如果列表懒加载配置没调好，首屏一次性渲染几十个商品，滑动会明显卡。我的做法是在鸿蒙适配层里把 FlatList 的 removeClippedSubviews 设为 true，同时把 windowSize 调低到 5 左右。实测列表滚动帧率从 40 帧提升到了 55 帧，和 Android 端的差距已经很小了。
4.4 鸿蒙 feature 模块与 HAR 封装，工程结构这样搭
鸿蒙的工程结构和 Android 的 Gradle 多模块有相似之处，但名字不一样：鸿蒙的模块叫 feature 或 har，其中 har 是静态共享库，feature 是可以独立编译的模块。商城项目涉及的功能模块很多，我建议按业务域拆分成多个 feature 模块，比如 feature_home、feature_category、feature_cart、feature_order、feature_user、feature_merchant，每个模块只负责自己的业务页面和组件。
为什么要拆这么细？因为鸿蒙的编译和热重载是按模块走的。业务模块拆开之后，改动一个模块不会触发整个工程的重新编译，开发体验会有质的提升。尤其是商城这种大项目，全量编译一次可能要五六分钟，而拆了模块后大部分改动只需要一两分钟。
原生桥接模块和第三方 SDK 的统一封装，要放到 har 类型的基础库中。我这边有一个 native_bridge.har，专门封装支付、分享、推送、定位的 ArkTS 桥接代码；还有一个 rn_runtime.har，封装 RN 环境的初始化、页面路由、错误处理。这两个基础库被所有 feature 模块依赖，任何页面要用原生能力，都从基础库导出，不允许业务模块里直接写桥接代码。这样当鸿蒙 SDK 更新引起桥接层变化时，只需要改一处，全局生效。
5. 实测环节：商城 App 在真机上的性能表现与兼容性报告
5.1 性能数据：冷启动、页面切换、内存占用
作为技术分享，光说思路没数据支撑是耍流氓。我这边选了三台设备做基准测试：一台是 Android 中端机（骁龙 778G 平台），一台是 iOS 设备（A15 芯片），一台是鸿蒙设备（麒麟 9000 系列）。测试场景设定为典型的用户路径：冷启动进入首页、滑动首页 20 个商品、进入商品详情、加入购物车、进入结算页。
先看冷启动数据。Android 端优化后冷启动耗时约 1.6 秒，iOS 端约 1.3 秒，鸿蒙端约 2.1 秒。鸿蒙端偏慢的原因除了 JS 引擎的加载差异外，还有鸿蒙系统的页面启动机制和 Android 不完全一样，RNPageAbility 的拉起自带一层渲染等待。这个差距目前只能靠优化 Bundle 加载时间和减少首屏初始化任务来弥补，想完全对齐 iOS 短期不太现实。
页面切换的流畅度上，首页信息流的滑动帧率三端基本都能稳定在 55 帧以上，Android 偶尔会有小掉帧，原因是部分低端机型的 GPU 性能瓶颈，不是 RN 本身的问题。详情页的图片加载体验鸿蒙端比 Android 稍差，主要是图片解码速度略慢，我这边把 react-native-fast-image 的缓存策略调整成了超大缓存上限，改善了一部分。内存占用方面，完整跑完一条购物流程，Android 端峰值约 480MB，iOS 约 420MB，鸿蒙约 510MB。鸿蒙端偏高，是因为 ArkUI 的原生组件映射层会额外占用一部分内存，后续版本应该会逐步优化。
5.2 兼容性清单：哪些功能正常，哪些要降级处理
实测下来，商城的主流功能在鸿蒙端基本都能正常工作，但有几个模块需要注意降级方案。第一个是地图模块：鸿蒙端的高德地图 SDK 目前覆盖的接口少于 Android，比如室内地图和自定义路线的能力缺失。我这边做了个降级策略：当检测到鸿蒙环境时，地图页面降级为静态地图服务，用图片标注替代交互式地图。这对商城 App 影响不大，但如果你的业务强依赖地图交互，这个坑要提前评估。
第二个是推送模块：鸿蒙的推送通道走的是华为推送服务，和 Android 的厂商通道机制不同，需要单独接入华为 Push Kit。如果只是简单地把 Firebase Cloud Messaging 或极光推送的 Android 版本直接搬过来，是收不到消息的。这块的适配工作量取决于你集成的推送服务商，好消息是主流国内推送厂商都已经发布了鸿蒙版本 SDK，但这些 SDK 的接口和 Android 版不兼容，需要重新集成。
第三个是热点分享和外部唤起。商城的分享功能在 Android 上是调起系统分享面板，鸿蒙的分享机制是系统服务，需要把分享代码单独抽出来写一层适配。我实测下来，鸿蒙的分享面板能够成功分享链接和图片到主流应用，但分享带自定义缩略图的场景不稳定，偶尔会出现图片不显示的问题。稳妥的做法是分享时直接使用 URL 链接，不传本地图片路径。
6. 踩坑实录：鸿蒙适配里最值得警惕的三个隐蔽问题
6.1 循环滚轮组件：RN 生态没有现成方案，只能手动改
最近热搜里提到“react native 如何实现循环滚轮”，这个需求在商城场景里很常见，比如用户选择一个数量、年龄段、或时间范围。RN 社区一直没有特别成熟的滚轮选择器，生态里最接近的 react-native-picker 还是基于 Android 原生 View 封装的，到了鸿蒙就完全失效了。
我这边自己封装了一个循环滚轮组件。原理是用 ScrollView 加 snapToInterval 实现逐项对齐，然后通过 onMomentumScrollEnd 监听滚动结束的位置，计算当前选中的索引。循环逻辑是通过在数据前后各补两段相同数据来实现的，滚动到边缘时自动跳转到中间对应项，实现视觉上的无限循环。这套组件在 Android 和 iOS 上表现都不错，鸿蒙端因为 snapToInterval 行为有点差异，需要把每一项的高度设成固定值，并且不能动态改变，否则对齐位置会飘。
这个组件的代码大概两百行左右，不复杂，但要注意滚轮在惯性强滑时的处理。用户快速滑动后，ScrollView 的惯性距离很长，如果数据项不够多，容易在中间停下而不是吸附到最近一项。目前是监听 onScrollBeginDrag，记录滑动起始位置，再结合速度估算目标索引，确保即使快速滑动也能精准对齐。
6.2 前景图与后景图配置错误：一个让启动页变黑屏的细节
热搜词里有条“未正确配置前景图和后景图”，这是鸿蒙工程配置里的典型陷阱。HarmonyOS 的启动页配置分为前景图 foreground 和后景图 background，如果只配了前景图没配后景图，或者图片格式不符合要求，启动时容易出现黑屏或者启动页一闪而过的问题。
我的经验是：前景图必须使用 PNG 格式，尺寸和系统要求严格匹配，后景图可以直接用颜色值，不一定要图片。启动页的配置在 module.json5 里通过 abilities 下面的 startWindowIcon 和 startWindowBackground 两个属性控制。RN 的鸿蒙适配层生成工程模板时，默认配置往往只是简单指向替代资源，如果你直接沿用，某些机型上会出现启动图像素拉伸或显示不全的问题。
排查这类问题最快的办法是查看鸿蒙设备日志里的 DisplayManager 相关输出，它会明确告诉你图片资源配置失败的具体原因。我这边遇到过的问题是前景图有透明通道，导致显示成黑色，后来在导出图片时去掉了 alpha 通道就正常了。这类细节不起眼，但恰恰是适配过程中最容易耗费时间的地方。
6.3 JavaScript 线程的日志阻塞，排查起来最隐蔽
最后一个坑不仔细看根本想不到。在鸿蒙的调试模式下，如果开发工具开启了较大的日志输出缓冲，JS 侧的 console.log 输出量过大会反过来阻塞 JS 线程的执行，直接导致 UI 卡顿和触摸事件延迟。商城的业务日志本来就多，像我这边首页一次加载会输出商品列表、推荐日志、埋点事件等几十条日志，在鸿蒙真机调试时页面明显掉帧。
处理办法比较直接：开发阶段用 __DEV__ 标志控制日志输出级别，生产环境关闭所有 console.* 调用，同时把日志模块封装成统一的 Logger 工具类，支持分级控制和批量丢弃。这个工具类在 Android 上影响不大，但在鸿蒙上能明显提升真机调试体验。另外，商城项目的埋点上报不要直接在业务代码里 console.log，要统一走埋点 SDK，既能保障性能，也方便数据治理。
7. 最后的工程化建议与下一步扩展方向
做完一轮完整的商城开发和鸿蒙适配之后，我最大的感触是：跨端开发的瓶颈从来不在写代码本身，而在于你能否预判每个端的能力边界和生态差异。鸿蒙这块市场还在快速变化中，官方文档和社区方案的更新频率比 Android/iOS 快得多，很可能你今天踩的坑，下个月官方就已经修复了。所以做鸿蒙适配，一定要有一套持续跟踪的设备测试清单，经典机型、新发旗舰机、平板设备都要覆盖到，别只看模拟器表现。
如果你团队的人力有限，我建议鸿蒙适配的重点优先级这样排：支付链路和登录链路是第一优先级，这两个做不好用户根本走不下去；商品浏览和加购是第二优先级，影响核心转化；营销玩法和消息推送放最后，可以走 WebView 降级过渡。这个排序不是我拍脑袋定的，是从用户价值角度做的取舍，你可以在自己的项目里按同样逻辑重新评估。
我这边后续的计划是继续优化鸿蒙端的首屏加载速度，逐步把营销页面从 WebView 迁移到原生 RN 页面以提升体验。另外，HarmonyOS 的纯血版本对 React Native 运行时提出了新的要求，团队也在关注从 RN 的 JS 运行时迁移到鸿蒙方舟运行时上的可能性。如果你也在做类似的事情，欢迎一起交流踩坑经验，这块的路还很长，结伴走会轻松不少。