鸿蒙商城App评价模块实战：基于React Native for OpenHarmony的完整实现

做OpenHarmony商城App这个项目的时候，我印象最深的不是首页里那些花哨的动效，反而是“写评价”这个看起来平平无奇的功能。原因很简单：它是用户下单之后最常碰到的操作入口，同时牵扯到评分交互、文本输入、图片上传、网络异常兜底，任何一环处理不好都会直接变成差评投诉。加上我们用的是React Native for OpenHarmony这套桥接方案，很多在Android/iOS上跑得好好的逻辑，到了鸿蒙上都得重新调一遍。今天就把这个实战模块从技术选型到最终落地的完整过程整理出来，给正在做或打算做鸿蒙商城类App的团队一个参考。

我把项目名定为rn_for_openharmony，本质上是把一个原本跑在Android/iOS上的React Native商城业务，通过OpenHarmony的RN适配层迁移到鸿蒙设备上。评价模块是其中一个Tab里的子页面，但它几乎覆盖了RN开发中90%的典型场景：本地状态管理、原生模块调用、图片权限处理、前后端联调、防重复提交。所以这篇文章不仅适合想了解RN在OpenHarmony上能不能用的朋友，也适合那些已经在做鸿蒙App、想优化评价体验的开发者。

1. 先说背景：为什么写评价这个模块值得单独做一篇

1.1 从用户和产品角度看评价模块

评价模块对电商类App的价值，远远不只是“给订单打分”这么简单。产品侧会拿评价内容做商品详情页的UGC填充，运营侧会统计好评率、晒图率来调整商家策略，连推荐系统都需要评价里的关键词来理解商品属性。换句话说，评价模块的填写率和内容质量，是直接影响后续业务转化率的核心指标。

但从技术角度讲，写评价又是一个异常集中的场景。用户可能在弱网下点提交，可能在相册里挑了一堆大图，可能输入到一半被系统杀了进程，也可能连续快速点提交按钮导致重复入单。我见过不少项目在评价接口上出的生产事故，大多是防重没做好或者图片没压缩导致请求超时。所以我在做这个模块的时候，提前把异常路径当成第一优先级来设计，而不是先把UI画出来再说。

1.2 技术选型历程：为什么选RN for OpenHarmony

我们团队的现状是：前端技术栈以React为主，已有的商城业务在Android/iOS上就是React Native实现的，沉淀了一批通用的业务组件和工具函数。如果鸿蒙端用ArkTS完全重写，等于要维护两套互不相通的代码，人力翻倍，而且两个端的UI细节很容易出现微小偏差。

当时对比了几条路：

• ArkTS原生开发：性能最好、系统能力调用最直接，但开发周期长，前端同学基本不能直接上手，需要单独组建鸿蒙团队。
• Flutter for OpenHarmony：跨端方案里渲染一致的体验很好，但当时Dart侧的第三方库适配还不太全，尤其是图片选择、上传这类需要调系统能力的场景，得自己写Platform Channel。
• React Native for OpenHarmony：OpenHarmony SIG官方一直在推进react-native-openharmony适配层，社区里也已经有不少常用组件完成了鸿蒙适配，比如react-native-image-picker的ohos版本、异步存储、网络请求相关的库。对我们这种已有RN业务沉淀的团队来说，迁移成本最低。

最终选择RN for OpenHarmony，核心原因是业务代码复用率高。我把原有商城项目里和平台强相关的代码剥离开之后，评价模块大约90%的JS/TS代码可以原样保留，主要改的是原生配置、权限声明、个别原生模块的调用方式。这个收益在人力紧张的情况下是非常划算的。

当然这套方案也有代价：RN在鸿蒙上的某些能力还比较新，遇到问题能查到的资料不多，基本得靠读源码和真机调试一点一点啃。后面第6部分我会把踩过的坑集中列出来。

1.3 商城项目结构与评价入口

整个商城App的模块划分大概是：首页、分类、购物车、订单列表、订单详情、个人中心、写评价（属于订单详情的二级入口）。用户从“待评价”的订单卡片点进去，订单详情页展示商品信息、价格明细、物流状态，底部有一个“去评价”按钮。

写评价页面需要拿到的基础数据主要有三类：

• 订单信息：订单号、下单时间、店铺名。
• 商品快照：商品ID、标题、图片、规格。这里有个细节：快照必须是下单时的数据，而不是实时的商品信息，否则用户评价时看到的价格和规格可能已经变了。
• 用户信息：用户ID、头像、昵称，用于生成评价记录和匿名态控制。

我在工程里定义了一个CommentTarget类型，用来在页面跳转时携带这些数据：

interface CommentTarget { orderId: string; goodsId: string; goodsTitle: string; goodsImage: string; specText: string; shopName: string; }

跳转时用路由参数传递，如果参数缺失就默认展示空态并给出提示。这一步虽然简单，但很影响体验：有些机型低内存下页面重建后参数丢失，需要支持用orderId重新拉取数据兜底。

2. 工程基础：RN for OpenHarmony部署与权限准备

2.1 从模板工程起步

如果你是第一次接触RN for OpenHarmony，我最推荐的方式是直接用官方维护的模板工程初始化，而不是自己手动搭。因为适配层的版本和React Native核心版本是绑定的，手动pin版本很容易踩到依赖不一致的坑。

初始化核心步骤大概是：

# 新建目录并初始化 mkdir rn_for_openharmony cd rn_for_openharmony # 使用ohos适配模板创建工程 npx @react-native-ohos/cli init RNHarmonyDemo # 进入工程目录，安装鸿蒙侧依赖 cd RNHarmonyDemo ohpm install

开箱模板里已经包含了entry模块，也就是鸿蒙侧的Native壳工程，以及React Native侧的业务代码目录。业务代码部分会有一个index.ets或MainPage.tsx之类的入口，在原生侧通过RNSurface或者自定义的RNOHCorePackage挂载到页面上。

这里要提醒一点：鸿蒙的构建系统是hvigor，它和Android的Gradle完全是两回事。你在网上搜索问题时，如果搜到的是Android Gradle的报错，大概率不能直接套用。常见的一个报错是could not determine the dependencies of task ':app:compiledebugjavawithjavac'，这是典型的Android工程写法，和鸿蒙的entry模块没关系，遇到类似的报错先检查是不是用错了构建工具。

2.2 权限和隐私合规

写评价这个页面涉及两个敏感系统能力：访问相册和调用相机。此外网络请求是基础必备能力。在OpenHarmony里，这些权限都需要在entry/src/main/module.json5里显式声明。

我这里用到的权限对照表：

user_grant类型的权限不会在安装时自动授权，必须在运行时通过Ability或者专门的原生模块主动请求。在RN层，我封装了一个requestPermission的工具函数，内部通过鸿蒙侧的abilityAccessCtrl申请权限，然后通过回调把结果传回JS侧。

另外一个很重要的点是隐私合规。国内做App都清楚，应用首次启动时需要弹出隐私政策弹窗，用户同意后才能申请敏感权限和初始化SDK。我们的做法是在原生入口的onWindowStageCreate阶段先判断是否已经同意隐私协议，如果没有，就弹一个原生Dialog；用户点同意后写入本地标记，再开始加载React Native的bundle。如果用户点拒绝，就直接退出或停留在空白页，避免在未授权的情况下触发任何网络请求。

2.3 数据通信基本配置

RN for OpenHarmony里JS侧和原生侧的通信走的是RN的标准Bridge机制，NativeModules、NativeEventEmitter这些API在鸿蒙适配层都实现了。不过有些系统能力的API差异比较大，比如图片选择，原版的react-native-image-picker在鸿蒙上不能直接用，得换成官方适配过的@react-native-oh-tpl/react-native-image-picker。

安装方式：

npm install @react-native-oh-tpl/react-native-image-picker ohpm install @react-native-oh-tpl/react-native-image-picker

注意这里有个双依赖的概念：因为RN库同时涉及JS侧和原生侧，所以既要用npm装JS包装，也要用ohpm装鸿蒙侧的Native实现。少装一个，运行时就会报“TurboModule无法解析”之类的错误。

网络请求我直接用的fetch，底层会走到鸿蒙的HTTP能力。有一个比较隐蔽的坑是：HTTP的证书校验策略、超时时间在鸿蒙上的默认值和Android不一样，最好在原生侧配置一下连接超时，否则弱网下请求会长时间挂起。

3. 评价页设计与核心组件拆解

3.1 页面结构与布局细节

评价页整体采用了ScrollView包裹的结构，因为内容可能很长，尤其是图片一多，小屏手机会溢出。页面的从上到下：

1. 商品信息区：商品缩略图 + 标题 + 规格，整块区域用卡片样式包起来。
2. 评分区：五颗星，支持点击和滑动切换。
3. 内容输入区：多行TextInput，占位符提示“说说这件商品的使用感受吧”。
4. 图片上传区：九宫格，前N格是已选图片，最后一格是加号按钮，点击唤起选择器。
5. 匿名开关：一个Switch组件，控制评价是否匿名展示。
6. 提交按钮：固定在页面底部，避免用户往下滚动时还要找按钮。

有一点很容易被忽略：TextInput在ScrollView内部时，快速滚动会触发输入框失焦，导致键盘收起，体验很割裂。我处理的办法是把keyboardShouldPersistTaps设置为handled，让点击非输入区域时不在滚动过程中直接收起键盘，而是先传递给子节点处理。

3.2 手写星级评分组件

评分组件看起来简单，但我选择手写而不是直接找第三方库的原因有两个：一是第三方库在鸿蒙上的触摸事件适配不稳定，二是评分组件的交互逻辑很简单，手写成本很低，还可以严格控制星星的大小、颜色、间距。

核心代码如下：

const StarRating = ({ value, onChange }: { value: number; onChange: (v: number) => void }) => { const [score, setScore] = useState(value || 0); const handlePress = (star: number) => { setScore(star); onChange(star); }; return ( <View style={styles.starRow}> {[1, 2, 3, 4, 5].map(star => ( <Text key={star} style={[ styles.star, { color: star <= score ? '#FF9500' : '#E5E5E5' } ]} onPress={() => handlePress(star)} > ★ </Text> ))} </View> ); };

细节处有两个要注意：

• 星星的点击热区要适当放大。直接用Text时，实际可点击区域可能只有文字本身那么一小块，用户很容易点不中。我给每个星星外面包了一层TouchableOpacity，并且用hitSlop扩大触控范围，实测这个改动对提升评分操作成功率非常有帮助。
• 状态更新要防抖。快速连续点击星星时，如果每次都触发父组件的onChange，会导致外层频繁setState，重渲染起来星星会有闪烁感。我的做法是评分组件内部自己维护score，只有最终选中后才回调父组件，这样就算点了一串星星，也不会引起无谓的全局重渲染。

评分规则方面，我们开放的是1到5的整数星，没有做半星。因为主流电商的评价体系里，半星反而会显得选项复杂，用户决策成本变高。后端在接口里也限制了socre字段只能是整数，校验逻辑前后端都做了一遍。

3.3 内容输入与字数限制

输入框用的是TextInput的multiline模式，最大高度限制在120，超过就内部滚动，避免页面被拉得无限长。占位符文案是产品定的，但我在实现时发现一个鸿蒙平台差异：占位符颜色在某些系统版本上默认是浅灰色，在浅色背景下几乎看不见，所以需要显式设置placeholderTextColor。

字数统计和最大限制这一块，坑比较深。很多人直觉上觉得text.length就是字数，但React Native的JavaScript引擎对中文字符统计是按UTF-16码元计算的，一个emoji会被算成2个长度。我们产品规定最多500字，如果直接用.length，用户输入一串emoji时统计会提前爆掉，体验相当差。

我采用的统计方式：

const normalizeLength = (text: string) => Array.from(text).length; const handleTextChange = (text: string) => { const len = normalizeLength(text); if (len > 500) return; setContent(text); setRemaining(500 - len); };

Array.from会把字符串按Unicode码点拆开，一个emoji算1个，一个中文也算1个，这样基本符合用户对“字数”的感知。当然这也不是绝对严谨，比如一些组合型emoji会被拆成多个码点，但实际业务中已经够用了。如果后端有统一的字数校验规则，前端统计方式最好跟后端对齐，否则会出现在前端能提交、后端反而报错的情况。

我还加了实时计数显示：“还可以输入xxx字”，当接近上限时数字变红，提示用户即将超限。这块纯属用户体验细节，但评价页面本身内容单一，这种小小的状态提示能有效降低用户输入焦虑。

3.4 匿名开关与商品信息复用

匿名开关实现很简单，一个Switch加一段说明文字“匿名评价，对所有人不可见”。这个信息要拼到提交参数里。有一点要注意：匿名不代表评分不可见，只是昵称和头像不展示，后端会单独用is_anonymous字段控制脱敏逻辑，前端不要自己在界面上隐藏评分。

商品信息区我把它封装成一个独立的GoodsCard组件，传入CommentTarget对象渲染。做成独立组件而不是直接写在页面里的原因是：订单详情页和评价页都要展示同一份商品快照，复用组件能保证两端的UI表现和数据类型完全一致，以后要改样式也只需要改一处。

在性能优化上，我给GoodsCard包了React.memo，因为商品信息在评价页面内是不会变化的，完全没必要随着输入框的内容变化而重新渲染。这一点在低端鸿蒙设备上效果非常明显，尤其是打开键盘或滚动时，整体帧率会更稳定。

4. 图片选择、压缩与上传链路

4.1 接入图片选择器

图片选择是评价模块里原生依赖最重的一块。我在鸿蒙上用的是@react-native-oh-tpl/react-native-image-picker，调用方式跟原版API基本一致。

选择相册图片：

import { launchImageLibrary } from '@react-native-oh-tpl/react-native-image-picker'; const pickImages = async () => { const result = await launchImageLibrary({ mediaType: 'photo', selectionLimit: 9 - selectedImages.length, }); if (result.assets) { const newImages = result.assets.map(asset => asset.uri); setSelectedImages(prev => [...prev, ...newImages].slice(0, 9)); } };

调用相机：

import { launchCamera } from '@react-native-oh-tpl/react-native-image-picker'; const takePhoto = async () => { const result = await launchCamera({ mediaType: 'photo', saveToAlbum: false, }); if (result.assets) { setSelectedImages(prev => [...prev, result.assets[0].uri].slice(0, 9)); } };

实际开发中有个比较棘手的问题：鸿蒙相册返回的URI可能以file://或content://开头，不同系统版本表现还不一样。如果直接拿这个URI去上传，服务端可能收到一个无法识别的路径。我封装了一个resolveImagePath工具，把URI转换成可以直接读取的本地文件路径，转换逻辑里兼容了ph:、file://、content://几种前缀。这块没有通用的银弹，最好的方法就是拿几台不同鸿蒙版本的设备多测几轮。

4.2 压缩策略

图片不压缩就直接上传，是评价模块性能问题的第一大来源。现代手机拍出来的照片动不动就是3-8MB，用户如果选满9张图，一次提交可能产生几十MB的请求体，弱网环境下基本必失败。

我在项目里用react-native-compressor做压缩，它的鸿蒙适配版同样带ohos前缀。压缩参数我调成：

const compressedUri = await ImageCompressor.compress(uri, { quality: 0.7, maxWidth: 1280, maxHeight: 1280, output: 'jpg', });

maxWidth和maxHeight都限制在1280，是为了在清晰度和体积之间取一个平衡点。评价里展示的图片最大也就是详情页里一个四分之三屏宽的大图，1280已经远超实际需求，继续保留原图分辨率纯属浪费。实测一张5MB的照片压缩后基本在300-500KB左右，九张图总量控制在4MB上下，上传体验要好很多。

这里有一个优化细节：压缩是CPU密集型操作，如果用户一次选了9张图，不要同步循环压缩，否则会造成明显的界面卡顿。我用的方案是限制并发数为3，把压缩任务拆成批次，每完成一个就更新进度提示，避免压缩时页面像死掉一样。

4.3 多图上传并发控制与进度反馈

图片上传我用的是XMLHttpRequest而不是fetch，原因是fetch在上传进度这一块支持很差，而XHR可以监听upload.onprogress事件，实时拿到上传百分比。RN的XMLHttpRequest实现里这个能力是可用的，只是很多人没注意到。

单个图片上传的核心代码：

const uploadSingleImage = (uri: string, index: number) => { const formData = new FormData(); formData.append('file', { uri, name: `comment_${Date.now()}_${index}.jpg`, type: 'image/jpeg', } as any); return new Promise<string>((resolve, reject) => { const xhr = new XMLHttpRequest(); xhr.open('POST', UPLOAD_URL); xhr.setRequestHeader('Authorization', `Bearer ${token}`); xhr.upload.onprogress = (e) => { if (e.lengthComputable) { const percent = Math.round((e.loaded / e.total) * 100); onProgress?.(index, percent); } }; xhr.onload = () => { try { const data = JSON.parse(xhr.responseText); if (xhr.status === 200 && data?.data?.picId) { resolve(data.data.picId); } else { reject(new Error(data?.message || '上传失败')); } } catch (err) { reject(err); } }; xhr.onerror = () => reject(new Error('网络异常')); xhr.send(formData); }); };

多图的并发控制我封装了一个简单的任务调度器：核心逻辑是始终只有3个上传任务在跑，每完成一个就从待上传队列里拉一个补上。好处是避免并发过高打爆设备网络栈，也让单张图片的进度回调不会在9张同时跑的时候乱作一团。

上传成功后，服务端返回的是图片ID（picId），我把它放进一个images数组，和短评文本一起用于提交评价接口。这样做有个好处：图片上传和评价提交是两件事，图片传失败了可以单独重试或删除，不需要把整个页面状态全都推倒重来。

5. 提交逻辑与异常兜底

5.1 接口约定与参数封装

评价提交接口的路径约定为POST /order/comment，请求体是JSON格式：

{ "orderId": "20250101001", "goodsId": "100200300", "score": 5, "content": "商品很好，发货也快", "images": ["picId_1", "picId_2"], "isAnonymous": false }

这里有几个接口设计层面的细节建议：

• images字段在服务端接收时一定要区分“未传”和“传空数组”两种情况。未传代表前端没有图片能力，传空数组代表用户一张图都没选。有些服务端框架对二者处理不当，会导致默认值污染数据。
• content允许为空，但前提是images不能为空数组，也就是说晒图评价可以不写字。这个规则要写死在接口文档里，前端校验时同步对齐。
• 如果将来要支持追加评价，接口里最好从一开始就带上commentType字段，既能兼容首评，也能在后续扩展追评场景，避免改表结构。

前端封装请求函数时，我会统一注入token、traceId、渠道号这些公共参数，并在网络层做一个错误码映射：401跳登录、500弹服务端错误、超时弹网络提示。这样评价页面的业务代码就不需要到处写重复的try/catch了。

5.2 前端校验

校验规则我放在三个层面：

• 评分必须大于0。这个校验看起来多余，但实际测试中我发现用户很容易只填文字忘了选星，如果后端直接把score当成0处理，这条评价就成了无效数据。
• 内容和图片至少有一个非空。两者都为空时点击提交，应该直接阻止并Toast提示“说点什么或传张图吧”。
• 内容长度不超过500字，图片数量不超过9张。这两个限制在前端做了强约束，理论上不会超，但为了防止手滑和极端情况，提交前再校验一次总没错。

校验不通过的提示方式，我用的是RN的ToastAndroid，在鸿蒙适配层也做了兼容。要注意Toast在“键盘弹起”状态下会被软键盘挡住，提示要延迟到键盘收起之后，或者干脆放在页面顶部用自定义横幅提示，实测体验更好。

5.3 防重复提交

防重复提交是评价接口最重要的一道防线。用户在网络慢的场景下，如果连续点击两次提交按钮，就可能产生两条一模一样的评价，处理起来非常麻烦。

我的做法是三层防护：

• 按钮状态层：提交中把按钮disabled并显示加载文案“提交中...”。这样用户第一次点击后，按钮已经不可点了。
• 标志位守卫：用一个useRef变量保存isSubmitting，在提交函数入口判断，如果为true直接return，避免异步回调里因为事件循环错乱导致重复执行。
• 服务端幂等：请求头里带一个clientRequestId（UUID），服务端在同一订单号下根据这个ID去重。前两层只是前端体验兜底，真正保证不重复入库的还是服务端这层幂等校验。

实现代码片段：

const isSubmitting = useRef(false); const handleSubmit = async () => { if (isSubmitting.current) return; isSubmitting.current = true; setBtnLoading(true); try { await submitComment(payload); Toast.show('评价成功'); navigation.goBack(); } catch (e) { // 恢复按钮状态，保留已输入内容 setBtnLoading(false); // 弹窗让用户选择重试或保存草稿 } finally { isSubmitting.current = false; } };

一个容易被忽略的点是：isSubmitting.current = false要放在finally里而不是try里。如果请求抛异常后直接返回，isSubmitting会一直是true，用户就再也提交不了评价了，这个bug非常隐蔽，测试时如果没走异常分支很难发现。

5.4 网络异常与草稿机制

网络异常处理我做了两件事：重试和草稿。

重试比较简单，用户点击重试只是重新走一遍handleSubmit流程，之前填写的score、content、images都保留在页面状态里，不存在丢数据的风险。

草稿机制则更考验细节。用户在写评价的过程中可能突然锁屏、切后台、甚至App被杀。如果把输入内容丢了，用户回来后心态崩溃，大概率就不填了。所以我在onChangeText时做了一个防抖，5秒内如果内容有变化，就异步写入AsyncStorage，key用orderId + goodsId做区分；用户下次再进入这个页面时，优先拉取本地草稿恢复内容，提交成功后再清除对应草稿。

草稿恢复到界面上时，有一个小坑：如果有图片是用本地路径临时存的，草稿恢复时这些路径很可能已经失效（比如App重启后临时目录被清掉）。所以草稿里只恢复评分、文本、匿名开关，图片不恢复，并在界面上提示“草稿已恢复，图片请重新选择”。这样至少保住了用户敲的字。

6. 真机调试与踩坑记录

6.1 启动白屏与bundle加载

RN for OpenHarmony开发时最常见的现象就是启动白屏。调试模式下，原生壳启动后会去连接Metro服务加载JS bundle，这个过程中如果Metro没启动、端口被占用、或者局域网IP不通，页面就一直白着。Android上如果Metro有问题会有红屏报错，鸿蒙适配层早期版本对加载失败的处理不够完善，往往什么都不显示。

我排查白屏的固定步骤：

• 确认Metro服务已经启动，端口默认8081。
• 确认真机和电脑在同一个局域网内。
• 在DevEco Studio的日志里搜“bundle”或“RNOH”相关关键字，看有没有加载失败信息。
• 如果测试包是release包，确认bundle已经正确打包进assets里，而不是仍然指向Metro。

针对线上兜底，我在原生侧做了一个启动超时机制：RN Surface加载超过10秒无回调时，展示一个内置的“加载失败请重启”页面，而不是一直白屏干等。这个体验对真实用户很重要，哪怕只是多一个错误反馈，也能避免大量“打开App是空白”的负面反馈。

6.2 键盘遮挡输入框

评价页面输入框在页面中部，键盘弹起时如果不处理，输入框很容易被软键盘遮住。Android的adjustResize在这里有效，但鸿蒙的窗口软键盘模式跟Android不完全一致。

我一开始直接用KeyboardAvoidingView，设置behavior="height"，在部分鸿蒙版本上表现正常，但在另一部分版本上完全没反应。后来我换成了手动监听键盘事件：

const [keyboardHeight, setKeyboardHeight] = useState(0); useEffect(() => { const subShow = Keyboard.addListener('keyboardDidShow', e => { setKeyboardHeight(e.endCoordinates.height); }); const subHide = Keyboard.addListener('keyboardDidHide', () => { setKeyboardHeight(0); }); return () => { subShow.remove(); subHide.remove(); }; }, []);

拿到键盘高度后，给ScrollView的contentContainerStyle动态加一个paddingBottom。这个方案比KeyboardAvoidingView稳定得多，而且可以精确控制滚动位置，让用户输入时光标所在区域自动滚到键盘上方。这个“获取高度+手动padding”的思路在RN跨端里通用，以后遇到类似问题也能复用。

6.3 依赖冲突与构建失败

鸿蒙工程的依赖管理同时涉及npm和ohpm两套体系，这也是最容易出问题的地方。比如react-native-image-picker的npm包和ohpm原生包版本不一致，hvigor构建时会直接报找不到模块。

我在第2部分提到过双依赖安装的逻辑。实际中光有ohpm包还不够，还需要在entry模块里对原生包进行注册，如果不注册，运行时报错是“table unknown”或者“module not found”。具体做法是在工程的原生入口文件里，把对应的TurboModule或Package实例注册进RN宿主。

另外有个非常容易踩的坑：npm包和ohpm包的版本号之间可能不是一一对应，需要看仓库文档里的兼容对照表。我遇到过一次npm装的是2.0.0，但ohos原生包只支持1.9.x，导致运行时某个方法报“undefined is not a function”。排查半天，最后还是把npm版本降级才解决。所以遇到奇怪标红，第一步不是改代码，而是检查依赖版本匹配度。

6.4 性能与渲染细节

评价页面在低端鸿蒙设备上的性能问题主要集中在这几处：

• 评分组件重渲染：如果评分组件的onChange冒泡到页面顶层并经setState触发全页面重建，输入框就会明显卡顿。我把评分组件内部状态独立持有，只在最终确认时回调，有效地把渲染范围限制在组件内部。
• 图片列表：已选图片的九宫格我用FlatList自带的numColumns渲染，而不是直接map。图片多的时候，只有可视区域内的item会被渲染，滑动体验顺滑很多。
• 提交按钮的loading态：提交过程会有压图片、传图片、提交评价多个阶段，每个阶段耗时都不同。我给按钮展示的是“X/N”进度比例，虽然实现稍微繁琐一点，但用户能明确知道当前卡在上传还是提交，不容易产生“点了没反应”的错觉。

另外，ScrollView+TextInput的组合在鸿蒙上还有一个比较微妙的问题：如果页面里放了很多图片缩略图，快速滑动时可能会因为图片解码排队导致掉帧。我建议图片的缩略图尺寸控制在200px左右，不要直接渲染原图的比例，哪怕压缩后的图片是1280宽，缩略图也单独生成一份。这一点在图片数量多的时候优化效果尤其明显。

写评价这个功能的代码量在整包App里占不了多大比例，但它的工程质量直接体现出一个团队对用户体验的用心程度。我个人最大的体会是：别因为页面简单就跳过异常处理，输入内容丢失、重复提交、图片上传失败，这些才是真正会引发用户流失的问题。在RN for OpenHarmony这种新生态上做开发，依赖版本和构建配置的坑会掩盖很多业务逻辑本身的问题，所以写功能前先把工程基础打扎实，后面会省钱得多。

最后再分享一个小技巧：评价模块的图片上传和内容提交，我建议从一开始就拆成两个独立接口。虽然这会增加一次网络请求，但换来的是“图片可重试、内容可草稿、状态可恢复”的灵活性。如果图省事把图片和文本绑成一个提交接口，一旦失联通杀，用户填的几百字就全没了。就冲这一点，我觉得拆开是最值的决定。