积分商城是我在接触鸿蒙跨端开发时做的第一个完整业务页面。原因很直接公司现有的 React Native 代码里已经有一套积分系统我不想因为 HarmonyOS NEXT 不再兼容安卓 APK就把整套业务逻辑用 ArkTS 重新写一遍。这篇就把“积分商品列表 积分兑换流程 兑换记录”这三个核心场景完整拆开走一遍在鸿蒙上用 React Native 实现积分商城页面的过程。这篇文章适合两类人一是已经在用 React Native 写业务、正在研究鸿蒙适配方案的前端开发二是刚接触鸿蒙生态、想了解跨端开发到底怎么落地的同学。我会把项目结构、状态设计、页面实现、调试踩坑都串起来讲不追求大而全只求能照着把页面跑起来同时理解每一步背后的选择。1. 项目整体设计与思路拆解积分商城不算复杂的业务但它把列表渲染、状态联动、请求反馈、空态加载这些 RN 日常开发里的高频场景都覆盖了。整个页面其实只做三件事展示用户当前积分和商品库存让用户用积分兑换商品兑换完能在记录列表里看到历史订单。1.1 积分商城的功能模块划分拿到需求后我先把页面拆成了四个模块积分余额头部、商品列表、兑换确认弹层、兑换记录页面。每个模块对应一套独立的状态和交互模块之间通过数据联动而不是直接操作对方内部状态。积分余额头部负责展示用户当前可用积分这是所有兑换操作的先决条件。商品列表展示可兑换的商品卡片每张卡片包含商品名称、所需积分、剩余库存和兑换按钮。兑换确认弹层在用户点击兑换后出现展示本次扣减预览让用户二次确认避免误触。兑换记录页面则单独作为入口展示历史兑换订单及状态。之所以把兑换记录拆成独立页面而不是塞在同一屏是因为真实项目里的记录状态流转往往比 demo 复杂得多待发放、已发放、已取消、物流单号等等。如果全部堆在一个页面交互层级会乱列表也会越来越长。拆开后商品页只关注“能不能兑换”记录页只关注“兑换后发生了什么”职责清晰。1.2 为什么选 React Native 做鸿蒙端在 HarmonyOS NEXT 之前鸿蒙 4.x 还能通过兼容层跑安卓 APK不少团队的 RN 应用是靠“套壳”续命的。但 NEXT 取消安卓兼容后这条路彻底断了。要把现有业务搬到鸿蒙上主流选择只有三条用 ArkTS 原生重写、上 Flutter、用 React Native 的鸿蒙适配层。重写成本最高。积分商城这个页面看着不大但它背后通常还连着登录、支付、消息推送等一堆基础设施全部重写等于从零起步。Flutter 的鸿蒙社区适配也在推进但如果你团队的主技术栈就是 JS/RN让所有人去学 Dart 再重写一遍培养成本和迁移成本都不低。所以我的选择是 RNOH也就是 React Native OpenHarmony 适配方案。它的核心思路不是把 RN 改成一个鸿蒙原生框架而是在鸿蒙壳工程里做一个桥接层JS 侧依然跑 React 的 Virtual DOM 和调度逻辑鸿蒙侧通过一套与安卓/iOS 版 RN 相似的机制把组件映射到 ArkUI 的原生组件上。你在 JS 里写一个 View鸿蒙端渲染出来的实际是一个 ArkUI 容器组件。这套适配层目前已经覆盖了大部分常用组件和 API。View、Text、TextInput、ScrollView、FlatList、Modal 这些基础组件都有对应实现对积分商城这种常规业务页面来说完全够用。1.3 交互流程与状态模型设计整个兑换交互流程我理成了这样进入页面拉取用户积分和商品列表渲染头部余额和商品卡片点击“立即兑换”弹出确认层确认后提交兑换请求根据返回结果更新余额、库存和记录列表最后用户可以点进兑换记录页查看历史订单。这个流程决定了状态模型。我用了 React 自带的 useReducer 而不是 Redux因为积分商城的状态虽然多但都围绕“积分和商品”两个核心实体相互之间耦合很紧用 reducer 集中管理比多个 useState 散落各处要清晰得多。const initialState { balance: 0, goods: [], records: [], loading: false, exchanging: false, }; function reducer(state, action) { switch (action.type) { case LOAD_START: return { ...state, loading: true }; case LOAD_SUCCESS: return { ...state, loading: false, balance: action.balance, goods: action.goods }; case EXCHANGE_START: return { ...state, exchanging: true }; case EXCHANGE_SUCCESS: return { ...state, exchanging: false, balance: state.balance - action.points, goods: state.goods.map(item item.id action.id ? { ...item, stock: item.stock - 1 } : item ), records: [action.record, ...state.records], }; case EXCHANGE_FAIL: return { ...state, exchanging: false }; default: return state; } }网络层我统一封装了一个 request 方法所有接口返回结构约定为{ code, data, message }。前端根据 code 判断业务是否成功而不是只看 HTTP 状态码。后端很多接口习惯在 HTTP 200 里塞一个业务错误码前端如果不做统一拦截会散落一堆 if/else 判断。2. 环境准备与工程初始化环境配置是整个项目里最容易被低估的部分。React Native 跑鸿蒙端不是简单创建一个普通 RN 项目就行它需要同时具备安卓/iOS 工程的基础工具链还得额外准备鸿蒙侧的 DevEco Studio 和对应 SDK。2.1 工具链清单我先列一下这次开发用到的工具和版本要求避免大家装到一半才发现缺东少西。工具用途建议版本Node.js跑 Metro、npm 依赖管理18 及以上JDK编译鸿蒙壳工程依赖的 Java 环境17 及以上DevEco Studio打开并编译鸿蒙壳工程、真机运行5.x配 API 12 SDKReact Native CLI创建 RN 工程、启动 MetroRN 0.72 及以上TypeScript类型提示积分商城这种业务量推荐用5.x很多人在这一步犯的错是只用 Android Studio 跑了一遍 RN 项目以为带上 DevEco Studio 就能直接打开鸿蒙工程结果版本对不上。RNOH 适配层的版本和 React Native 版本、鸿蒙 SDK 版本是绑定的装之前建议先查一下你要用的 RN 版本对应支持哪个鸿蒙 API Level再根据这个装 DevEco Studio 的 SDK。2.2 初始化鸿蒙 RN 工程用 RNOH 的脚手架初始化工程后目录里会多出鸿蒙侧的子工程。整体结构大致如下目录/文件作用src/JS 业务代码跨端共用android/安卓壳工程ios/iOS 壳工程ohos/ 或 harmony/鸿蒙壳工程给 DevEco Studio 使用package.json依赖和脚本metro.config.jsMetro 打包配置初始化流程我建议按这个顺序走用脚手架创建一个带鸿蒙模板的 RN 工程。命令格式类似npx react-native-ohos/cli init YourProjectName具体命令以当前版本文档为准。进入工程目录执行npm install把 JS 侧依赖装齐。用 DevEco Studio 打开鸿蒙壳工程目录。首次打开会自动同步 Gradle 配置和鸿蒙 SDK等待同步完成。配置签名证书。开发阶段直接用 DevEco Studio 的自动签名功能在 Project Structure 里勾选自动签名即可它会帮你生成调试证书。启动 Metronpm start或者npx react-native start。在 DevEco Studio 里选择真机或模拟器点击 Run 按钮编译运行鸿蒙壳工程。这里有个关键点Metro 必须先启动鸿蒙壳工程运行时会去连接 Metro 拉取 JS bundle。如果 Metro 没起或者在真机上 Metro 地址配置成了 localhost就会出现典型的启动白屏。2.3 三方库选择的避坑建议React Native 的生态很丰富但在鸿蒙适配层上第三方原生库的支持还在逐步完善。很多 npm 包在安卓和 iOS 上跑得很稳一上鸿蒙就崩或者功能缺失原因是它们内部依赖了原生模块而鸿蒙侧还没有对应实现。积分商城这个项目我用到的库非常克制。网络请求直接用全局的 fetch日期处理直接用内置方法连图标都没有引入 vector-icons 那类依赖原生字体的库优先级是“先用纯 JS 方案不行再找鸿蒙适配过的原生库”。UI 组件库更不建议无脑引入。常见的 Ant Design React Native、React Native Elements 这类库底层多半依赖原生组件在鸿蒙端可能出现样式错乱或点击事件失效。我的做法是手写 UI 封装。积分商城也就四五个界面组件卡片、弹窗、按钮、空态视图。手写成本一点都不高好处是三个端视觉完全一致还避开了适配层的未知坑。提示如果你的项目实在需要某个原生库先查它是否支持 OpenHarmony或者用react-native-oh-tpc这类鸿蒙适配过的第三方组件索引。3. 核心页面实现与代码拆解这一部分是正文的核心。我会按页面模块逐个拆代码从主题配置、商品列表、兑换提交到兑换记录完整走一遍。3.1 页面骨架与主题配置多端统一视觉的第一步是定义设计变量。没有设计变量的话同一个色值在三个平台各写一遍后续改主题色能找到人崩溃。// src/theme.js export const colors { primary: #FF8F1F, bg: #F5F6FA, card: #FFFFFF, textMain: #1F2329, textSub: #8A919F, danger: #E34D59, success: #56C271, border: #EBEDF0, }; export const spacing { xs: 4, sm: 8, md: 12, lg: 16, xl: 24, };页面最外层我封装了一个 PageContainer统一处理背景色和 SafeArea 适配。鸿蒙的 SafeArea 逻辑和安卓不太一样直接用系统状态栏高度计算容易出偏差用 RN 内置的 SafeAreaView 组件做适配它在鸿蒙适配层上也有对应实现。// src/components/PageContainer.js import React from react; import { SafeAreaView, StyleSheet, View } from react-native; import { colors } from ../theme; export default function PageContainer({ children, style }) { return ( SafeAreaView style{styles.safe} View style{[styles.container, style]}{children}/View /SafeAreaView ); } const styles StyleSheet.create({ safe: { flex: 1, backgroundColor: colors.bg }, container: { flex: 1, backgroundColor: colors.bg }, });3.2 积分余额头部与商品卡片列表积分余额头部我用了 Card 样式左侧放用户当前可用积分右侧放一个“兑换记录”入口按钮。积分数字用toLocaleString(zh-CN)做千分位显示比如 12800 显示成 12,800视觉上更清晰。商品数据在开发阶段先用 mock 数据。我的建议是mock 数据尽量贴近真实接口返回结构字段名和类型要和后端约定一致这样以后接真实接口时只需要替换数据源UI 层完全不用动。// src/mockData.js export const MOCK_GOODS [ { id: 1, name: 电影票50元券, points: 1200, stock: 8, coverColor: #FF9F45 }, { id: 2, name: 蓝牙耳机, points: 6800, stock: 3, coverColor: #6D8BFF }, { id: 3, name: 帆布袋, points: 300, stock: 20, coverColor: #56C271 }, ]; export const MOCK_RECORDS [ { id: R20250701001, goodsName: 电影票50元券, points: 1200, time: 2025-07-01 10:23, status: pending, }, { id: R20250628002, goodsName: 帆布袋, points: 300, time: 2025-06-28 15:41, status: done, }, ];商品列表我用 FlatList 而不是 ScrollView 加 map。原因很简单积分商城上架 50 个商品后ScrollView 会把所有 item 一次性渲染出来滚动明显掉帧FlatList 是懒加载只渲染当前窗口附近的内容列表一长差距立刻能感觉到。商品卡片组件长这样// src/components/GoodsCard.js import React from react; import { View, Text, Pressable, StyleSheet } from react-native; import { colors, spacing } from ../theme; function GoodsCard({ item, balance, onPress }) { const priceDisabled balance item.points; const stockDisabled item.stock 0; const disabled priceDisabled || stockDisabled; return ( View style{styles.card} View style{[styles.cover, { backgroundColor: item.coverColor }]} / View style{styles.info} Text style{styles.name} numberOfLines{1}{item.name}/Text Text style{styles.stock} {item.stock 0 ? 剩余 ${item.stock} 件 : 已兑完} /Text View style{styles.bottomRow} Text style{[styles.points, priceDisabled styles.pointsDisabled]} {item.points.toLocaleString(zh-CN)} 积分 /Text Pressable disabled{disabled} onPress{() onPress(item)} style{[styles.btn, disabled styles.btnDisabled]} Text style{[styles.btnText, disabled styles.btnTextDisabled]} {stockDisabled ? 已兑完 : 立即兑换} /Text /Pressable /View /View /View ); } const styles StyleSheet.create({ card: { flexDirection: row, backgroundColor: colors.card, borderRadius: 12, padding: spacing.md, marginBottom: spacing.md, }, cover: { width: 80, height: 80, borderRadius: 8, }, info: { flex: 1, marginLeft: spacing.md, }, name: { fontSize: 16, fontWeight: 600, color: colors.textMain, }, stock: { fontSize: 12, color: colors.textSub, marginTop: 4, }, bottomRow: { flexDirection: row, alignItems: center, justifyContent: space-between, marginTop: 8, }, points: { fontSize: 16, fontWeight: 700, color: colors.primary, }, pointsDisabled: { color: colors.textSub, }, btn: { backgroundColor: colors.primary, paddingHorizontal: 16, paddingVertical: 6, borderRadius: 16, }, btnDisabled: { backgroundColor: colors.border, }, btnText: { color: #fff, fontSize: 13, fontWeight: 600, }, btnTextDisabled: { color: colors.textSub, }, }); export default GoodsCard;按钮的禁用逻辑是这里最容易忽略的细节。积分不够和库存不足是两个完全不同的禁用原因文案和视觉要区分开。如果库存为 0 还显示“立即兑换”用户点了之后又弹错误提示体验很差。所以我直接用 stock 判断按钮文案让用户一眼知道为什么不能点。3.3 积分兑换确认与提交逻辑用户点击“立即兑换”后不直接发请求而是先弹确认层。这一步能有效防止误触也能在弹层里展示“兑换后余额为多少”的预览信息让用户心里有数。弹层我用 RN 自带的 Modal 组件实现半透明遮罩加底部卡片。// src/components/ExchangeConfirmModal.js import React from react; import { Modal, View, Text, Pressable, StyleSheet } from react-native; import { colors, spacing } from ../theme; function ExchangeConfirmModal({ visible, item, balance, submitting, onCancel, onConfirm }) { if (!item) return null; const remain balance - item.points; return ( Modal visible{visible} transparent animationTypefade onRequestClose{onCancel} View style{styles.mask} View style{styles.card} Text style{styles.title}确认兑换/Text Text style{styles.goodsName}{item.name}/Text View style{styles.pointsRow} Text style{styles.label}本次兑换/Text Text style{styles.points}-{item.points.toLocaleString(zh-CN)} 积分/Text /View View style{styles.pointsRow} Text style{styles.label}兑换后余额/Text Text style{[styles.remain, remain 0 styles.remainDanger]} {remain.toLocaleString(zh-CN)} 积分 /Text /View View style{styles.btnRow} Pressable style{[styles.btn, styles.cancelBtn]} onPress{onCancel} Text style{styles.cancelText}再想想/Text /Pressable Pressable style{[styles.btn, styles.confirmBtn]} disabled{submitting || remain 0} onPress{onConfirm} Text style{styles.confirmText} {submitting ? 提交中... : 确认兑换} /Text /Pressable /View /View /View /Modal ); } const styles StyleSheet.create({ mask: { flex: 1, backgroundColor: rgba(0,0,0,0.45), justifyContent: center, paddingHorizontal: spacing.xl, }, card: { backgroundColor: colors.card, borderRadius: 16, padding: spacing.xl, }, title: { fontSize: 18, fontWeight: 700, color: colors.textMain, marginBottom: spacing.md, }, goodsName: { fontSize: 14, color: colors.textSub, marginBottom: spacing.lg, }, pointsRow: { flexDirection: row, justifyContent: space-between, marginBottom: spacing.sm, }, label: { fontSize: 14, color: colors.textSub, }, points: { fontSize: 14, fontWeight: 700, color: colors.danger, }, remain: { fontSize: 14, fontWeight: 700, color: colors.textMain, }, remainDanger: { color: colors.danger, }, btnRow: { flexDirection: row, marginTop: spacing.lg, }, btn: { flex: 1, paddingVertical: 10, borderRadius: 8, alignItems: center, }, cancelBtn: { backgroundColor: colors.bg, marginRight: spacing.md, }, confirmBtn: { backgroundColor: colors.primary, }, cancelText: { color: colors.textMain, }, confirmText: { color: #fff, fontWeight: 600, }, }); export default ExchangeConfirmModal;提交兑换的核心逻辑我写在页面容器里。这里有个很重要的决策积分商城涉及余额扣减我用的是“先请求后更新”等后端明确返回成功才改本地状态。而不是一上来就用“乐观更新”先把 UI 改了。原因很简单用户看到“兑换成功”但积分没扣后面一定会来投诉。积分是真实资产宁可多等几百毫秒也不能给用户错误预期。const handleExchange async () { if (!currentGood) return; dispatch({ type: EXCHANGE_START }); try { const result await submitExchange({ id: currentGood.id }); // 这里假设后端返回 { code: 0, data: { record } } dispatch({ type: EXCHANGE_SUCCESS, id: currentGood.id, points: currentGood.points, record: result.record, }); setConfirmVisible(false); showToast(兑换成功可在兑换记录中查看); } catch (error) { dispatch({ type: EXCHANGE_FAIL }); showToast(error.message || 兑换失败请稍后重试); } };请求成功后要同时做三件事扣减余额、减少商品库存、往记录列表头部追加一条新记录。这三件事在 reducer 的 EXCHANGE_SUCCESS 分支里一次性完成保证状态联动一致。如果分开写在多个地方很容易漏掉其中一个。3.4 兑换记录列表兑换记录页相对独立数据入口是记录列表。每条记录包含商品名称、兑换时间、消耗积分、状态。状态我用状态码映射成中文文案并配上不同的颜色让用户扫一眼就能判断当前进度。// src/utils/status.js export const RECORD_STATUS { pending: { label: 待发放, color: #FF9F45 }, done: { label: 已发放, color: #56C271 }, cancel: { label: 已取消, color: #8A919F }, };记录列表用 FlatList 渲染外层包一层 RefreshControl 支持下拉刷新。下拉刷新在积分商城里是刚需因为用户兑换后可能想立刻看到记录更新总不能每次退出页面重进。空态布局是列表页面最容易忽略的细节。没有记录时直接白屏会显得很简陋我加了一个简单空态组件一行图标加文案提示“暂无兑换记录快去兑换心仪商品吧”。3.5 网络层封装与异常处理网络层我做了统一封装核心代码如下// src/api/request.js const BASE_URL https://your-api-host.com; const request async (path, options {}) { const res await fetch(${BASE_URL}${path}, { method: options.method || GET, headers: { Content-Type: application/json, ...(options.headers || {}), }, body: options.body ? JSON.stringify(options.body) : undefined, }); if (!res.ok) { throw new Error(HTTP Error: ${res.status}); } const json await res.json(); if (json.code ! 0) { throw new Error(json.message || 业务请求失败); } return json.data; }; export const fetchGoods () request(/goods); export const fetchRecords () request(/records); export const submitExchange (payload) request(/exchange, { method: POST, body: payload, });因为开发阶段没有后端我在 service 层加了一层 mock 适配用 setTimeout 模拟网络延迟。这样 UI 的 loading 状态、失败重试逻辑都能提前验到。等后端接口就绪只需要把 service 层内部的实现换成真实 request 调用组件代码完全不用改。异常处理上我统一在 catch 里做 Toast 提示并恢复按钮的 loading 状态。这里的一个心得是不要把 catch 里的提示词写死成“网络错误”优先抛出后端返回的 message因为后端往往会提示具体的业务原因比如“积分余额不足”或“商品已下架”。3.6 数据联动与状态管理的取舍这个小节我想单独说说为什么不用 Redux 或 MobX。积分商城的页面状态其实只有一组balance、goods、records外加两个 loading。这些状态相互关联但不跨模块共享。useReducer 加页面级 useState 完全够用引入全局状态库反而增加心智负担和样板代码。useReducer 还有一个好处是状态更新逻辑集中尤其适合这种“一个成功动作要同时改三处数据”的场景。如果不用 reducer而是分别 setBalance、setGoods、setRecords很容易在某个回调里漏掉一个。再说一下“乐观更新”。有些列表类场景我确实会用乐观更新比如点赞、收藏先把 UI 切成目标状态再等接口返回失败时回滚。但积分兑换涉及余额扣减用户对“余额是否扣对”极其敏感所以我选择保守策略提交按钮显示 loading等后端确认后再更新。这样虽然多一次等待但换来的是信任感值得。4. 调试运行与常见问题排查实录写业务代码其实是整个开发过程里最顺的部分真正磨人的是调试。RN 在鸿蒙上的调试链路比纯安卓要长涉及 Metro、鸿蒙壳工程、签名、网络配置多个环节任何一个环节出问题都会以“白屏”或“请求失败”的形式呈现非常容易原地懵掉。4.1 在鸿蒙模拟器和真机上跑起来DevEco Studio 自带的模拟器可以用来跑鸿蒙工程适合开发前期快速验证页面 UI。但模拟器性能一般而且部分涉及系统能力的调试不完整我建议真机为主、模拟器为辅。真机运行步骤如下鸿蒙手机上开启开发者模式在“设置-系统-开发者选项”里打开 USB 调试。USB 连接电脑手机弹窗选择“允许调试”。DevEco Studio 的设备列表里会识别出真机点击 Run 按钮部署运行。在真机上启动应用时需要确认 Metro 的地址可以被手机访问到。如果把 localhost 当成 host真机是访问不了电脑本地服务的要改成局域网 IP。开发阶段我建议用真机加 Metro 热更新的组合。Metro 跑起来之后鸿蒙壳工程会直接从 Metro 拉取最新 bundle你改 JS 代码保存后页面几乎秒级刷新体验和安卓开发完全一样。如果每次改代码都要重新编译鸿蒙工程效率会非常低。4.2 RN 启动白屏的排查实录“React Native 启动白屏”是我在搜索热词里看到出现频率很高的问题我自己也踩过而且是开发过程中最典型的坑。白屏不等于代码报错它通常是某个前置条件没满足页面根本没加载起来。我的排查顺序是固定的先看 Metro 终端是否有编译输出。如果 Metro 没启动或者编译报错鸿蒙壳工程只能拿到空 bundle页面自然是白的。再看鸿蒙侧的日志。DevEco Studio 的 Log 窗口里搜 “ReactNative” 关键字桥接层会打印 bundle 加载结果和异常堆栈这里能看到是不是加载中间出错了。检查设备访问 Metro 的地址。真机最容易犯的错就是 host 配置成 localhost改成电脑的局域网 IP 后问题就消失了。最后才怀疑页面代码本身。拿一个最简单的 View 渲染测试能让白屏问题快速收敛到业务代码层。排查时切忌乱猜。我曾经在 Metro 地址没问题的情况下一直怀疑是鸿蒙壳工程配置问题结果翻日志发现是某个依赖包没装完整。养成“先看日志再动配置”的习惯能省很多时间。4.3 网络请求在鸿蒙上的坑网络层是鸿蒙适配里最折磨人的地方。HarmonyOS NEXT 对网络安全要求更严格明文 HTTP 流量默认是受限的。开发阶段如果后端接口是 http 而不是 https会出现请求发不出去或者直接报错的情况。解决方式有两种一是优先使用 https 接口二是在鸿蒙工程里配置网络安全策略放行特定域名。我建议直接选 https省得后面上生产还要改。有网友提到的“Android 请求正常鸿蒙请求 2300056”这个错误码我也遇到过类似情况。2300056 这个错误码本质上是一个网络连接层异常常见诱因包括证书校验失败、目标域名不可达、请求被网络安全策略拦截。遇到这类错误我先抓包看请求到底有没有发出去、响应体是什么。在 DevEco Studio 里可以用内置的 Profiler 抓包也可以借助 Charles 这类抓包工具看请求和证书链。确认是证书问题后检查是不是用了自签名证书开发环境可以让后端挂到测试域名上别在本地用 IP 直连。注意RN 端网络异常不能只看 HTTP 状态码。fetch 在部分异常情况下可能只抛出 TypeError而不带状态码。封装 request 时一定要统一 catch否则页面会直接崩溃连提示都弹不出来。4.4 常见错误速查表我把常见的坑整理成了一个速查表方便遇到问题时对照排查。现象可能原因排查与解决冷启动白屏Metro 未启动或 bundle 地址配置错误确认 Metro 终端有输出真机把 localhost 改为局域网 IP部分组件渲染白块三方原生组件未适配鸿蒙换成纯 JS 实现检查 react-native-oh-tpc 适配索引请求报 2300056证书、网络策略或目标地址问题抓包看请求是否发出检查证书链优先用 https真机安装失败签名证书未配置在 DevEco Studio 里开启自动签名点击兑换无反应Pressable 层级被遮挡或 disabled 条件误判检查组件层级打印按钮的 disabled 计算值兑换成功后列表没刷新数组直接增删改未使用不可变更新用 map/filter 生成新数组再 setState积分显示为负数弹层未拦截余额不足的点击在 confirm 弹层里校验 remain 小于 0 时禁用确认按钮5. 实操复盘与扩展方向最后一个章节我想复盘一下几个关键决策再说说这个项目以后还能怎么扩展。5.1 几个关键决策复盘第一为什么没上 Redux。积分商城的页面状态虽然多但都局限在单个页面内跨模块共享的需求很弱。useReducer 加状态集中管理已经足够。Redux 的精髓是跨模块状态同步和可预测性这里用不上反而会增加样板代码。第二为什么手写 UI 组件而不是引第三方库。鸿蒙适配层对 RN 原生模块的支持还不算全面常见的 UI 库底下多多少少都带原生依赖。积分商城组件就那么几个手写成本低还能保证三端视觉一致。如果项目里有复杂的图表、富文本编辑器这类高成本组件再考虑找鸿蒙适配过的成熟方案。第三为什么开发阶段用 mock 数据。积分商城这种业务前端和后端往往是并行开发的。早点把 UI 和交互跑通能提前发现很多产品层面的问题比如按钮文案、空态、错误提示这些在 mock 阶段就能调优不用等后端就绪。mock 数据的字段结构要和后端约定一致这比什么都重要否则后期替换数据源一样得改 UI 层。5.2 积分商品后续可以扩展的功能现在这个版本只是一个基础框架实际落地还有很多可以扩展的点。商品列表可以加分页加载和分类筛选商品多了以后一次性拉全部数据会让首屏变慢分页加 FlatList 的 onEndReached 就能搞定。商品卡片可以加“仅剩 N 件”的高亮角标利用稀缺感提升兑换转化率。兑换记录可以接物流状态已发放的商品显示物流单号用户就不用反复找客服问进度了。再往后积分商城可能会需要接入真实的用户系统根据用户等级展示不同的商品池和积分折扣。或者增加签到任务、积分流水让用户能看清楚每笔积分的来龙去脉。这些功能落在架构上无非是增加新的接口和状态分支目前这套 reducer 加 service 的结构可以平滑扩展。我在实际测试中还有一个体会React Native 在鸿蒙上的开发体验比想象中顺。只要 JS 业务代码不依赖那些只支持安卓或 iOS 的原生 SDK迁移成本非常低。积分商城这套实现从搭建工程到跑通全部流程时间主要花在环境配置和真机调试上写页面本身反而很快。如果你手头也有成熟的 RN 页面建议找个类似积分商城这样中等复杂度的页面先试水把鸿蒙的壳工程和调试链路摸熟后续迁移其他模块心里就有底了。最后分享一个开发效率小技巧鸿蒙调试阶段保持 Metro 一直开着鸿蒙工程会自动加载最新 bundle。这样改完 JS 保存页面刷新基本是秒级比每次手动打包再安装高效太多。这套开发节奏理顺之后你会发现跨端开发和普通 RN 开发的区别远没有想象中那么大。
