React Native鸿蒙跨平台实战：Zustand状态管理与条件渲染构建个性化推荐

这两年我经常被问到同一个问题：手里同时要维护鸿蒙、iOS、Android三端的存量用户，产品迭代节奏又特别快，跨平台方案到底怎么选才不踩坑。尤其是在华为生态逐步成熟、纯鸿蒙不再兼容安卓应用之后，这个问题已经从“要不要做”变成了“怎么做得更稳”。我目前的答案很明确：基于React Native跑鸿蒙跨平台，业务逻辑全部交给JavaScript，配合状态管理和条件渲染，把个性化推荐这类复杂业务从服务端到端侧做成一套可配置、可复用的链路。

这篇文章没有太多概念性的铺垫，直接讲我实际跑通这条链路的过程。核心就是三件事：为什么用React Native撑起鸿蒙跨平台，状态管理和条件判断应该怎么组织，以及个性化推荐模块如何一步步落地。适合正在评估跨平台方案的团队，也适合刚接触RN鸿蒙开发、打算把推荐场景做深的朋友。文章里的代码和踩坑记录都来自真实项目，可以直接照抄或改改再用。

1. 方案选型：为什么我最终选了React Native跑鸿蒙跨平台

1.1 跨平台方案三选一：RN、Flutter、原生，谁更合适

在鸿蒙生态刚起步的那段时间，团队内部开过很多次技术选型会，核心纠结其实绕不开三种路线。

第一种是原生三端各写一套。iOS用Swift/OC，Android用Kotlin/Java，鸿蒙用ArkTS/ArkUI。好处是性能完全可控、平台能力调用直接，但代价非常现实：一个简单的推荐位调整，要三个客户端依次排期、依次发版，迭代周期直接从“天”变成“周”。对一个只有几个移动端开发的小团队来说，长期并行维护三套代码基本不现实。

第二种是用Flutter。Flutter的渲染一致性极好，一套Dart代码绘制的UI在iOS、Android、鸿蒙上都能保持像素级统一。但问题也很明显：Dart语言相对小众，前端团队切进Flutter的学习成本比React Native高不止一个量级；另外Flutter在鸿蒙上的适配路线更多依赖社区插件，遇到卡点的时候排查成本比较高。

第三种就是我最终选择的React Native。RN的核心思路是用JavaScript或TypeScript写业务逻辑和UI声明，渲染时通过桥接层映射到原生组件。鸿蒙端接入RN适配层之后，你在代码里写的View、Text、Image、FlatList等组件，最终渲染出来的是鸿蒙ArkUI原生组件，而不是WebView套壳，也不是自绘Canvas。滚动、点击、无障碍、系统字体这些系统能力都能保留原生体验，这是RN对比H5方案的绝对优势。

选RN还有一个非常实际的原因：团队里前端工程师最多，客户端开发稀缺。React Native允许前端同学用JS生态里熟悉的那套工具链直接开发移动端，不要求每个人都懂Swift或ArkTS。从协作模式上看，业务逻辑、状态管理、条件渲染全在JS层，前端和后端通过接口契约对齐，客户端同学只负责端侧桥接和原生能力封装，人力瓶颈一下子就被打破了。

1.2 RN在鸿蒙上的运行机制与价值内核

很多人以为RN在鸿蒙上只是“跑起来了”，实际上它的运行机制跟iOS/Android完全一致：JS引擎（JSC或Hermes）负责执行业务代码，原生内核负责UI渲染。JS引擎和原生层之间通过桥接层进行通信，鸿蒙适配层则把RN组件逐一映射到ArkUI组件上。

这里要理解一个关键点：RN跨平台的本质不是“渲染层统一”，而是“逻辑层统一”。UI最终还是要落到每个平台的原生组件上，但业务判断、数据组装、状态流转这些核心逻辑完全由JS控制。这意味着你可以在JS层做大量平台差异兼容：比如鸿蒙端某个组件表现不一致，可以通过一个条件判断，单独为鸿蒙平台返回不同的样式或属性，而不需要改原生代码。

这套机制对个性化推荐尤其有价值。推荐服务本身就是逻辑密集型场景：要判断用户画像、要匹配运营策略、要处理加载失败、要区分空状态和成功态。这些逻辑如果写在原生层，每个平台都要重新实现一遍；写在JS层，一次实现三端生效。再加上RN支持动态下发JS更新包，运营策略当天配置当天生效，不用等应用商店审核，这对电商导购、内容资讯类产品来说是决定性的效率优势。

2. 状态管理：把业务逻辑从组件里抽出来

2.1 一个推荐模块到底要管理哪些状态

很多初学者写React组件，习惯把所有状态都塞进useState，页面一复杂就陷入“状态地狱”。这里我先不急着写代码，先拆一下推荐模块里到底哪些东西是状态。

我习惯把状态分成四层。第一层是用户画像状态，包括用户ID、人群标签、会员等级、是否新用户、地理位置、活跃时段、行为偏好得分等。第二层是推荐策略状态，包括当前命中的策略标识、策略版本号、策略优先级、是否强制展示。第三层是推荐数据状态，包括推荐位数据是否加载中、加载失败还是成功、返回的内容列表、分页游标。第四层是UI交互状态，包括当前选中的tab、推荐卡片是否展开、曝光埋点是否上报等。

这里要记住一个原则：所有需要跨组件共享、跨页面传递、影响多个页面渲染的状态，统一收拢到全局状态管理；只有跟当前组件UI强相关的临时态，才留在组件内部。比如“推荐卡片是否展开”这属于组件内UI态，用useState就够了；但“当前命中的推荐策略”会影响列表里的每个卡片渲染方式，必须放到全局状态里，否则页面一刷新就丢。

2.2 状态库选型：Zustand为什么比Redux Toolkit更好用

Redux Toolkit在React生态里非常成熟，团队人数多、需要强约束、需要时间旅行调试的场景它很合适。但我在RN鸿蒙项目里，实际推荐的是Zustand。原因不是Redux不好，而是推荐场景下的需求更加轻量直接。

Zustand的API极其精简，不需要定义Action、Reducer、ActionCreator那一整套样板代码。一个create方法把state和修改方法都定义好，组件里按需订阅。最关键的是它的订阅粒度非常细：只有使用了某个状态切片的组件才会重新渲染。这个特性在推荐信息流里特别重要，因为一个页面可能有几十个推荐卡片，如果每次状态变化都触发全列表reconcile，性能损耗会非常明显。

Zustand还有两个很实用的中间件。一个是persist，可以把用户画像、策略Key、上次加载时间直接持久化到本地存储，App冷启动之后秒级恢复状态；另一个是devtools，可以接入Redux DevTools做时间旅行调试，排查状态变化从哪里触发、为什么渲染异常。

相比之下，Redux Toolkit在大型复杂应用里约束力更强，但学习成本和样板代码也更高。对于RN鸿蒙这类“业务逻辑要快、迭代节奏要快”的项目，Zustand的上手速度和维护成本都更友好。

2.3 用Zustand落地推荐状态store的完整示例

放一个我项目中简化的推荐状态store示例，你可以直接照着改造。这里我用的是HarmonyOS场景下的一个电商导购App首页推荐模块：

js复制import { create } from 'zustand';
import { persist } from 'zustand/middleware';

const useRecommendationStore = create(
  persist(
    (set, get) => ({
      // 用户画像状态
      userProfile: null,
      // 推荐数据状态
      feedData: [],
      feedStatus: 'idle', // idle | loading | success | error
      // 推荐策略状态
      strategyKey: 'default',
      // 设置用户画像
      setUserProfile: (profile) => set({ userProfile: profile }),
      // 拉取推荐数据
      fetchFeed: async () => {
        const { userProfile } = get();
        if (!userProfile) {
          set({ feedStatus: 'error' });
          return;
        }
        set({ feedStatus: 'loading' });
        try {
          const data = await API.fetchRecommendation({
            userId: userProfile.userId,
            tags: userProfile.tags,
            level: userProfile.level,
          });
          // 根据画像和返回数据，判断当前命中的策略
          const strategyKey = profile.isNewUser
            ? 'new_user_gift'
            : profile.level === 'vip'
            ? 'vip_weekend'
            : 'default_feed';
          set({ feedData: data.items, strategyKey, feedStatus: 'success' });
        } catch (e) {
          set({ feedStatus: 'error' });
        }
      },
      // 重置状态
      reset: () =>
        set({ feedData: [], feedStatus: 'idle', strategyKey: 'default' }),
    }),
    {
      name: 'recommendation-store',
      version: 2, // 缓存版本号，重要
    }
  )
);

export const useProfile = () => useRecommendationStore((s) => s.userProfile);
export const useFeedData = () => useRecommendationStore((s) => s.feedData);
export const useFeedStatus = () => useRecommendationStore((s) => s.feedStatus);
export const useStrategyKey = () => useRecommendationStore((s) => s.strategyKey);

组件里订阅状态切片，只拿自己关心的那一段：

jsx复制import { useProfile, useFeedData, useFeedStatus, useStrategyKey } from '../stores/recommendationStore';

function RecommendationFeed({ onItemPress }) {
  const profile = useProfile();
  const feedData = useFeedData();
  const feedStatus = useFeedStatus();
  const strategyKey = useStrategyKey();

  useEffect(() => {
    if (profile) {
      useRecommendationStore.getState().fetchFeed();
    }
  }, [profile]);

  // 不同策略状态返回不同组件
  if (feedStatus === 'loading') return <SkeletonFeed />;
  if (feedStatus === 'error') return <ErrorFeed onRetry={() => useRecommendationStore.getState().fetchFeed()} />;
  if (!feedData.length) return <EmptyFeed />;
  return <FeedList data={feedData} strategyKey={strategyKey} onItemPress={onItemPress} />;
}

这里我多说几个实际心得。第一，状态永远不要存可以计算出来的东西。比如“用户是否新用户”这种判断，直接用userProfile.isNewUser字段，不需要单独存一个isNewUserState，否则两处状态容易不一致。第二，本地持久化一定要带version字段。服务端策略版本升级后，如果客户端的缓存结构跟新代码不兼容，轻则渲染异常，重则直接白屏。第三，任何网络请求都要有loading、error、success三个状态，千万别只存一个数据字段，否则UI层的骨架屏、错误重试、空状态都没法做。

3. 条件判断与条件渲染：JS语法的正确打开方式

3.1 条件判断的几种写法与应用场景

React Native跨平台场景下，条件判断的载体就是JavaScript本身。这里不讨论语法基础，直接讨论在推荐业务里怎么选择合适的判断写法。

if/else是使用频率最高、最直观的写法。它适合复杂多分支逻辑，尤其适合放到独立的策略函数里。优点是可读性好、扩展性好，每加一种策略就加一个分支；缺点是如果全堆在render函数里，组件会变得非常臃肿，所以我的建议是“if/else只出现在策略函数中，不出现在JSX里”。

三元表达式适合简单二选一的UI分支。比如“用户有会员标识就显示会员标签，否则显示普通标签”，这样一行搞定，非常清爽。但一旦嵌套超过一层，可读性就急剧下降，我建议嵌套两层以上的场景改用函数提炼。

逻辑与（&&）是React里最常用的单分支写法。条件为真才渲染指定内容，否则渲染空。这个写法的坑在于：如果条件是数字0或空字符串，会被误判为渲染对应值。比如{items.length && }在items为空数组时会渲染一个0，所以一定要写成{items.length > 0 && }。

逻辑或（||）和空值合并（??）看似相似，实际区别很大。||会把0和空字符串当作假值处理，而??只处理null和undefined。在推荐位展示场景里，默认值兜底应该用??而不是||，否则“推荐位序号为0”这类合法值会被错误替换。

可选链（?.）也是必备技能。用户画像在加载过程中可能是null，直接访问profile.level会抛“Cannot read property 'level' of null”。写成profile?.level，没加载完就返回undefined，配合默认值，代码稳很多。

3.2 从if/else到策略映射表：条件渲染的进阶思路

条件渲染最基础的写法是三元表达式和逻辑与，但在这之上，我认为最值得投入的是策略映射表（Strategy Map）模式。这个模式的思路是：把“判断逻辑”和“渲染组件”解耦。

举一个很典型的场景：首页推荐位在不同策略下，需要展示完全不同的卡片样式。新人策略展示“新人专享礼包”，会员策略展示“会员限时折扣”，夜间策略展示“深夜安静模式”，偏好策略展示“你可能喜欢”的个性化列表。

如果直接在JSX里用if/else写，代码会长这样：

jsx复制function renderFeed() {
  if (strategyKey === 'new_user_gift') {
    return <NewUserGiftFeed />;
  } else if (strategyKey === 'vip_weekend') {
    return <VipWeekendFeed />;
  } else if (strategyKey === 'night_mode') {
    return <NightModeFeed />;
  }
  return <DefaultFeed />;
}

这种写法本身不复杂，但问题在于：每加一种策略，就要改一次组件，违反了开闭原则。而且策略一多，这个函数会越来越长，新人接手也很容易在庞大分支里迷路。

更好的做法是定义一个策略到组件的映射表：

jsx复制const STRATEGY_COMPONENTS = {
  new_user_gift: NewUserGiftFeed,
  vip_weekend: VipWeekendFeed,
  night_mode: NightModeFeed,
  digital_hot: DigitalHotFeed,
  default_feed: DefaultFeed,
  empty: EmptyRecommendation,
};

function renderByStrategy(strategyKey) {
  const FeedComponent = STRATEGY_COMPONENTS[strategyKey] || DefaultFeed;
  return <FeedComponent />;
}

这样后续加策略，只需要新写一个组件，然后在映射表里注册一行，核心逻辑完全不用动。这种模式非常适合个性化推荐这类策略快速迭代的场景。

3.3 推荐策略分支的代码示例

现在来看一个更完整的例子。假设我有一个首页用户：VIP会员、活跃时段在晚上22点、设备是华为鸿蒙、偏好数码产品。系统需要根据这些标签决定推荐位的展示策略。

我先把策略判断收敛成一个纯函数，不依赖任何UI状态，方便单测也方便复用：

js复制// 策略判断纯函数
export function evaluateStrategy(profile, feedData) {
  if (!profile || !feedData || feedData.length === 0) {
    return { key: 'empty', reason: 'no_data' };
  }
  // 新用户：优先展示新人礼包
  if (profile.isNewUser && !profile.hasReceivedGift) {
    return { key: 'new_user_gift', reason: 'new_user' };
  }
  // VIP会员 + 周末：展示会员专属权益
  if (profile.level === 'vip' && isWeekend()) {
    return { key: 'vip_weekend', reason: 'vip_weekend' };
  }
  // 夜间时段：切入夜间模式，减少打扰性营销
  if (profile.isNightActive) {
    return { key: 'night_mode', reason: 'night_active' };
  }
  // 偏好匹配：数码偏好用户优先推荐数码热销
  if (profile.preferences.includes('digital')) {
    return { key: 'digital_hot', reason: 'preference_match' };
  }
  // 默认兜底：谁都不满足，给普通信息流
  return { key: 'default_feed', reason: 'default' };
}

随后在渲染层只负责消费strategyKey，然后根据映射表选组件：

jsx复制const STRATEGY_COMPONENTS = {
  empty: EmptyRecommendation,
  new_user_gift: NewUserGiftFeed,
  vip_weekend: VipWeekendFeed,
  night_mode: NightModeFeed,
  digital_hot: DigitalHotFeed,
  default_feed: DefaultFeed,
};

function RecommendationFeed() {
  const profile = useProfile();
  const feedData = useFeedData();
  const strategyKey = useStrategyKey();

  if (!strategyKey) return null;
  const FeedComponent = STRATEGY_COMPONENTS[strategyKey] || DefaultFeed;
  return <FeedComponent data={feedData} profile={profile} />;
}

这种写法最直观的好处是：添加策略不改老代码，只新增一个分支和一张映射配置，出问题的概率大大降低。而且条件判断和UI渲染隔离，想给策略引擎写单元测试也非常容易，直接对evaluateStrategy传不同profile断言返回的key就行。

这里提一个我踩过的坑：不要在渲染循环里直接调evaluateStrategy。这个函数虽然不重，但如果一个FlatList有几十个item，每次render都重复判断，累加起来性能就很差。我的做法是：策略判断在store的fetchFeed中只执行一次，把结果存进strategyKey，渲染阶段直接消费，避免重复计算。

4. 个性化推荐服务的完整实现路径

4.1 数据层：用户画像从哪来、怎么存

个性化推荐的第一步，是把用户画像建起来。画像数据一般有两个来源。第一个是服务端全量画像，用户启动App时通过接口拉取，包括会员等级、人群标签、历史消费类目、设备信息等。第二个是客户端本地行为画像，比如用户在推荐位的曝光、点击、加购、下单，通过埋点SDK上报之后，服务端异步加工再更新画像。

本地存储方面，我推荐用MMKV这类高性能键值存储，或者直接依托Zustand的persist中间件。画像数据属于低频读、频繁写的数据，冷启动时从本地缓存读出来，比等服务端接口返回要快得多，能显著减少推荐位白屏时间。但注意，本地画像一定要带时间戳，超过有效期（比如24小时）后以服务端数据为准，避免画像过期导致推荐不准确。

涉及隐私的数据要合规处理。用户点击记录、浏览历史这类行为数据，能脱敏就做脱敏处理，展示给推荐引擎时只保留特征标签，不保留原始行为链条。如果后续涉及加密传输，国密SM2、SM3、SM4这类加密算法在JS层和Java层都有完整实现，建议在服务端与端侧通信链路上做加密保护，避免用户信息在网络传输中被截获。

4.2 逻辑层：策略引擎的优先级设计与兜底

推荐策略引擎是整个模块的核心。它不是一个简单的if/else堆叠，而是一个带优先级的策略匹配系统。

我的设计思路是：把策略按业务权重排序，依次匹配，命中的最高优先级策略生效。这里的优先级是业务规则，比如新用户礼包的优先级通常高于偏好推荐，因为拉新转化的价值更高；VIP会员权益的优先级高于普通偏好推荐，因为付费用户需要更强的服务感知。

为了实现优先级系统，我建议把策略配置抽出来，交给服务端动态下发，客户端只负责解析和匹配。类似这样：

json复制{
  "configVersion": 8,
  "strategies": [
    { "key": "new_user_gift", "priority": 100, "match": "isNewUser && !hasReceivedGift" },
    { "key": "vip_weekend", "priority": 90, "match": "level === 'vip' && isWeekend" },
    { "key": "night_mode", "priority": 60, "match": "isNightActive" },
    { "key": "digital_hot", "priority": 50, "match": "preferences includes 'digital'" },
    { "key": "default_feed", "priority": 10, "match": "true" }
  ]
}

客户端拿到配置后，按priority排序，逐条解析match表达式，命中即返回。服务端动态下发的核心价值是：运营调整策略优先级不用发版，客户端SDK轮询配置就能立刻感知，对快速试错非常有利。

这里有一个必须处理的底线问题：如果服务端配置下发失败、本地没有缓存、策略引擎抛异常，怎么办？我的答案非常简单粗暴——兜底策略。任何异常都不能让页面白屏，最终一定有一个default_feed或者缓存的历史feed顶上。我把这个规则写死在代码里，不依赖服务端下发，保证极端情况下依然有内容可看。

4.3 UI层：推荐位模块的组件化状态机

UI层不建议直接从数据层映射组件，而是要设计一个状态机。推荐位模块一共有五个状态：idle（初始态）、loading（加载中）、error（失败）、empty（空数据）、success（成功态）。

• idle：还没有触发请求，不展示任何内容，或者展示占位容器。
• loading：展示骨架屏（Skeleton），让用户感觉页面在加载，而不是一片空白。
• error：展示“网络异常”提示和重试按钮，点击后重新触发fetchFeed。
• empty：展示空状态插图，提示“没有合适的推荐内容”，同时埋点上报未命中原因。
• success：展示策略匹配后的推荐列表。

这个状态机和状态管理store是一一对应的。我在代码里用feedStatus字段表示当前状态，渲染层根据状态切换组件。这样最大的好处是逻辑收敛：不会出现在某一次请求失败后，渲染层还在展示上一次的旧数据。

4.4 容错与降级：推荐服务挂了，页面也不能白屏

推荐服务是依赖服务端接口的，只要涉及网络，就一定会遇到超时、限流、数据异常。端侧必须有一整套降级方案。

第一级降级是本地缓存降级。如果服务端请求失败，但本地有上一次成功的feed缓存，先展示本地缓存，同时在页面角落标记“内容可能不是最新”。第二级降级是策略兜底。如果没有缓存、也没有数据，就走default_feed策略，展示一个固定的运营内容池。第三级降级是UI兜底。即便最终渲染失败，也必须有empty状态组件，不能让推荐区域变成空白的控件。

还有一个很重要的细节：和服务端接口对接时，要约定好失败但需要部分成功的场景。比如服务端返回的20条推荐里，有3条商品图片已经下架了，客户端需要做单条容错，把异常item过滤掉再渲染，而不是因为一张坏图导致整个列表渲染失败。这种边界处理写起来很简单，但确实能避免很多线上事故。

5. 常见问题与排查技巧实录

5.1 React Native启动白屏，从哪几处入手排查

React Native启动白屏算是出现频率最高的问题之一，我在鸿蒙端的调试环境里也遇到过好几次。白屏的本质是JS层还没有渲染出第一帧，所以排查重点围绕“JS代码为什么没跑起来”展开。

我通常按下面几步排查。先看JS bundle是否加载成功，确认Metro dev server是否在运行、端口是否被占用、包是否成功打进鸿蒙应用；再确认鸿蒙端RN适配层和应用的SDK版本是否匹配，适配层初始化失败会导致JS引擎已经启动但组件映射没有建立，页面就一直空白；接着看Hermes引擎是否正常初始化，如果切换了JS引擎，需要检查对应引擎的so库是否打包完整；最后排查首屏是否有大量同步任务阻塞JS线程，比如在组件外同步读取大文件、执行复杂加解密，这些会拖慢第一帧渲染。

启动白屏在Release模式的表现通常和Debug模式不一样。我建议遇到白屏先切Release包试试，如果Release正常而Debug白屏，问题大概率出在调试服务连接环节；如果Release也白屏，优先怀疑SDK版本不匹配或JS引擎初始化异常。

5.2 状态不同步与本地缓存版本混乱

Zustand的persist中间件很香，但也带来了一个经典问题：服务端策略配置升级了，客户端的本地缓存还停留在旧版本。最典型的场景是，运营调整了策略优先级，但老版本App的用户打开后，推荐位还在执行旧策略，导致线上数据看起来“策略没生效”。

解决这个问题有几个关键动作。第一，本地持久化store必须带version字段，每次state结构有变更就递增版本号。Zustand的persist提供了version配置，还可以通过migrate回调做数据迁移，老版本缓存在新代码加载时会被自动清洗。第二，服务端接口返回配置版本号，客户端每次拉取数据时对比版本号，不一致就强制刷新本地缓存并重置相关状态。第三，用户从本地缓存恢复画像后，必须发一个异步请求校验画像是否过期，过期就用服务端画像覆盖。

这里我多说一句：千万别图省事，在每次启动时都清空所有缓存。这样一来用户画像和策略状态每次都重新拉取，和没做本地持久化没有区别；二来状态恢复到默认值，会导致条件渲染短暂地挥一下默认组件，视觉上就是推荐位闪一下然后才变成正确内容。

5.3 条件渲染切换时的闪烁与性能抖动

推荐位策略切换时最常见的问题，是新内容渲染过程中出现滚动条跳动、图片闪烁、列表整体重排。这通常是因为策略切换后，新列表的item高度和旧列表不一致，FlatList无法复用已渲染的cell，只能全部重新渲染。

我建议从几个方面优化。第一，用React.memo包裹推荐卡片组件。只要传入的data和profile引用没变，就不重新渲染，这能显著减少策略切换时的无效DOM更新。第二，给FlatList设置好extraData，把strategyKey传进去，保证策略切换时列表能感知并重新计算。第三，策略切换时先展示loading骨架屏，等新数据返回后再渲染正式内容，避免“旧内容瞬间消失、新内容还没到位”的空白闪动。第四，所有推荐位内容的高度尽量保持稳定，比如图片使用固定宽高比，避免item高度变化引发布局漂移。

还有一个小坑要提醒：不要在render函数里用内联箭头函数创建组件，比如const Item = ({ item }) => {...}。这样每次render都会生成一个新的组件引用，React会认为组件类型变了，导致整个列表卸载再挂载，性能损耗非常大。推荐卡片组件应该定义在组件外部，保持引用稳定。

5.4 鸿蒙端组件兼容性和图片异常处理

鸿蒙的ArkUI组件体系虽然在持续完善，但RN某些组件在鸿蒙端的行为和iOS/Android还是存在差异。我在实际项目中遇到最典型的两个问题：一个是ScrollView的bounces回弹属性，iOS有天然回弹，Android和鸿蒙需要传bounces={true}才能模拟出类似效果；另一个是Modal弹层的透明度层级，鸿蒙端的Modal在某些系统版本上背景遮罩默认是全黑的，需要手动设置transparent属性才能呈现半透明效果。

图片加载方面，鸿蒙端对本地图片路径的处理和Android有差异，推荐位的运营图片建议全部走HTTPS网络地址，不用本地文件路径，能避免很多兼容性问题。如果一定要用本地图片，使用require方式打包进应用的资源，而不是拼写一个绝对路径字符串。

一旦遇到组件行为不一致，先用条件判断按平台区分。React Native的Platform模块能帮我们优雅处理：Platform.OS === 'harmony'时给某个属性设置特殊值，iOS和Android保持原有写法。这是RN跨平台开发的核心能力，也是鸿蒙适配最顺手的工具。

我个人在这套React Native鸿蒙跨平台方案里最深的体会是：状态管理和条件渲染不是炫技术，它们更像是把复杂业务逻辑拆解成清晰模块的施工工具。尤其是在鸿蒙生态还在快速迭代的环境里，策略逻辑收敛到纯JS函数和状态切片里，前端团队才能快速接手、快速试错，不会把精力耗在平台适配的琐碎细节上。最后再分享一个小经验：如果你想在鸿蒙上跑通RN的个性化推荐，建议从最核心的推荐信息流入手，先把“数据层-状态层-渲染层”这条链路跑顺，再逐步扩展策略类型和组件样式。这个地基打得越稳，后面加策略、调UI、做AB实验都会轻松很多。