企业官网建设流程全解析

直接说结论：React Native 跑在 OpenHarmony 上，Redux 中间件开发的核心逻辑和传统前端并没有本质区别，但在工程接入、调试手段、原生能力联动上，坑确实比想象中多。这篇文章我不会给你贴一堆官方文档的翻译，而是把我自己从环境搭建到中间件落地整个过程里，真正踩过的坑、反复验证过的写法，尽量完整地整理出来。标题里的三个关键词——React Native、OpenHarmony、Redux 中间件——每个单拎出来都有不少资料，但串在一起讲落地实战的确实不多，这篇补上。

先说清楚这个组合到底解决什么问题。跨端业务团队普遍面临一个现实：原生应用要覆盖不同系统生态，但人力有限，一套业务代码能同时跑在多个平台上是最理想的状态。React Native 本身就是干这个的，而 OpenHarmony 生态成熟度还在爬坡期，社区适配层出现之后，很多原本只做移动端的团队开始把目光投到这里。Redux 则是状态管理的经典方案，它足够规矩、可预测，中间件机制又提供了非常好的扩展点，适合在跨端场景里统一处理日志、异步、原生能力桥接这些横切关注点。如果你正在做 RN 适配 OpenHarmony 的工程化探索，这篇文章可以直接当参考手册用。

1. 这个技术点到底在解决什么问题

1.1 为什么要在 OpenHarmony 上选 React Native

OpenHarmony 作为一个新兴的分布式操作系统，应用生态肯定没办法一蹴而就。对这个生态里的早期团队来说，纯原生开发的问题很直接：人才储备少、组件库不全、UI 还原成本高。而 React Native 的引入带来了一个非常现实的好处——业务代码的复用率可以做到非常高。

我实际验证过的一个项目里，业务逻辑层和 UI 组件的复用率能到 70% 以上，剩下需要调整的主要是平台差异、系统 API 调用和少量的样式适配。这个比例对团队来说已经是巨大利好，因为前端团队可以无缝参与进来，不需要重新学一套基于 TypeScript 和 ArkUI 的原生开发模式。

另外一点，React Native 的架构设计本身足够干净。JS 层只关心业务逻辑和 UI 描述，原生层负责实际渲染和系统能力调用，这层天然的隔离让跨端适配变成了"只要桥接层能用，上层业务就不用大动"。OpenHarmony 侧的 RN 适配层做的就是这个事，把 JS 引擎、渲染引擎和原生模块都接到了 OpenHarmony 的能力上。作为应用开发者，我们接触到的就是一套基本兼容的 RN 开发体验。

1.2 Redux 在跨端状态管理里的角色

为什么选 Redux 而不选其他的？说实话，跨端场景里状态管理最怕的就是"各端各搞一套"，最后逻辑不一致、调试成本高。Redux 的核心约束——单一数据源、状态只读、用纯函数修改状态——这三个规则放在跨端场景里特别有价值。

在 OpenHarmony 上跑 RN，业务代码要同时面对 JS 引擎、原生渲染和系统事件，这些来源五花八门的状态变化如果不经过统一的状态容器，很容易出现"界面状态和实际数据对不上"的问题。Redux 的 store 就是唯一的数据源，任何状态变化都必须通过 action 显式触发，这让跨端联调时排查问题有迹可循。

而中间件机制恰好是 Redux 设计里最精妙的部分。它像一层洋葱皮包在 dispatch 外面，让你可以在 action 到达 reducer 之前做拦截、做处理、做转发。日志记录、异步请求、原生能力调用这些横切逻辑，全部都能优雅地放进中间件层，不需要污染业务组件代码。这就是为什么在跨端项目里，中间件开发往往决定了状态管理方案好不好用。

1.3 OpenHarmony 环境下中间件开发的特殊土壤

在 OpenHarmony 上写 Redux 中间件，和纯 Web 端的差别主要集中在几个地方。

第一是 JS 引擎不完全一样。OpenHarmony 的 RN 适配层用的是方舟运行时作为 JS 引擎，它对 ES 规范的符合度在逐步完善，但某些新 API 可能支持得不够及时。这要求中间件代码尽量别用特别激进的语法特性，减少潜在兼容问题。

第二是原生桥接能力的差异。在 iOS 和 Android 上，RN 有成熟的桥接生态，想调用什么原生能力都有现成模块。OpenHarmony 的适配层起步晚，桥接模块的丰富度有限，很多能力需要自己封装。这就让中间件多了一个新用途——作为原生能力的统一入口。在中间件里处理桥接调用，比在业务组件里到处 fetch 原生模块要干净得多。

第三是调试工具链。Web 端有成熟的 Redux DevTools，OpenHarmony 环境下调试器的连通性和稳定性都不如预期，很多调试手段需要自己想办法，比如用原生日志模块把关键信息打出来。这些问题在后面会详细展开。

2. Redux 中间件的运行机制与设计拆解

2.1 中间件如何改造 dispatch 流程

Redux 中间件看上去很玄，原理其实一句话就能说清：它就是一层包在 dispatch 外面的高阶函数，在 action 流向 reducer 的路上"插了一脚"。

最标准的中间件形式是柯里化函数：

const middleware = store => next => action => { // 在这里可以拿到 store、next 和 action return next(action) }

三个参数各有什么作用，得拆开看：

• store 提供getState和dispatch，但这里不能直接调store.dispatch，不然会形成递归，必须用next往下传。
• next指向下一个中间件或最里层的原生 dispatch，调用它就是"放行"。
• action就是被派发的动作，可以在放行前修改、放行后观察。

调用链的整体形态也顺带说一下，Redux 的applyMiddleware内部会把这些中间件按顺序组合起来，dispatch 从最外层中间件进入，一层一层往内传递，最后到达 reducer。这个过程用生活化类比来理解，就是快递包裹逐层过安检，每一层安检只负责自己的工序，然后传给下一站，直到送达目的地。

2.2 三种典型中间件范式

理解了上面那个函数签名，你就可以写出各类中间件。常见的范式大致分三类，我分别起个通俗名字：

日志巡检型：action 派发前后记录状态快照、耗时、错误信息。这类中间件主要用于观测。在 OpenHarmony 上跑业务时，Redux DevTools 未必可靠，自己写一个日志中间件把数据送到原生日志系统，往往更直接。

异步任务型：处理 action 是函数或包含异步副作用的情况，让 dispatch 支持 thunk、支持请求竞态控制。这类中间件解决了 Redux 本身不支持异步 action 的问题，是业务开发里最常用的一类。

能力桥接型：拦截特定类型的 action，调用原生模块完成系统能力调用，然后在回调中派发新 action 更新状态。在 OpenHarmony 上，这类中间件会越来越多，因为原生能力封装是跨端项目的刚需。

范式归范式，实际项目里经常是复合的。一个中间件既做日志，又做异步控制，也是常见写法。但设计上我倾向职责单一，方便组合，后面遇到问题也好排查。

2.3 OpenHarmony 场景下中间件的边界设计

在 OpenHarmony 上写中间件，除了通用的中间件设计原则，还得额外考虑三个边界。

第一个边界是原生调用失败的回退。OpenHarmony 原生模块的稳定性需要时间打磨，桥接调用失败、超时是家常便饭。中间件里调用原生能力，必须有超时保护和降级策略。我的做法是给桥接调用包一层 Promise.race，超时就派发一个失败 action，并携带降级数据。

第二个边界是平台差异化逻辑的隔离。同一种业务操作，在不同平台上的实现可能完全不同，比如日志上报、文件存储、设备信息获取。中间件内部做平台判断或者从配置中心拿能力实现，比在业务代码里到处写 if else 要整洁得多。

第三个边界是状态快照的序列化。OpenHarmony 上如果要打日志，状态快照很可能要通过桥接送到原生侧。但 store 里的状态如果包含函数、Map 这类不可序列化的数据，直接传过去就会出问题。所以日志中间件里做深度序列化是一个必要的防御动作。

有了这些边界意识，接下来看实操才有参考价值。

3. 环境准备与工程接入

3.1 搭建基础工程

先说环境部分，如果你之前跑过 RN 的移动端开发，那大部分依赖是可以复用的。这里只说 OpenHarmony 相关的特殊步骤。

• 安装某 IDE，并配置好 OpenHarmony SDK。这一步需要确认 SDK 的版本和 RN 适配层要求的版本匹配，版本不匹配会导致原生工程初始化失败。
• 创建一个标准的 OpenHarmony 工程，包名和应用名按自己业务定。
• 引入社区维护的 React Native for OpenHarmony 适配层。这块在工程里是作为一个原生依赖集成进去的，具体接入方式以对应版本仓库的 README 为准。
• 写一个最简单的页面，加载 RN 的 JS bundle，跑通"Hellworld"级别的渲染链路。

我当初在这步卡了挺久，核心问题是 IDE 版本和 SDK 版本配套不上，导致原生工程一直编译失败。建议不要追求都最新，而要看适配层的 release note 里写明验证过的版本组合。

3.2 在 JS 侧引入 Redux 和中间件

原生工程跑通之后，JS 侧的操作就熟悉了。用 npm 安装 react-redux 和 redux，然后在入口文件里组装 store：

import { createStore, applyMiddleware } from 'redux' import rootReducer from './reducers' import { loggerMiddleware } from './middlewares/logger' import { asyncMiddleware } from './middlewares/async' const store = createStore( rootReducer, applyMiddleware( loggerMiddleware, asyncMiddleware ) )

这里要留意applyMiddleware的参数顺序。中间件是按你传入的顺序执行的，内层的中间件会被外层的包裹。日志中间件放最外层，才能记录到最完整的 action 流。异步中间件放后面，请求动作进来时先过日志，再做异步处理，这样日志里能看到原始 action，也方便观察后续派发的成功或失败 action。

3.3 原生侧能力预检

在正式写中间件之前，建议先确认几个原生能力在 OpenHarmony 上是否可用，不然中间件写到一半发现桥接不通就尴尬了。

• 日志输出：JS 侧 console 日志能否在 IDE 的日志面板里看到？如果不能，需要封装一个原生日志模块。
• 异步存储：有没有可用的键值存储模块？Redux 的持久化中间件依赖它。
• Toast 和弹窗：用于调试提示和用户交互反馈。
• 网络请求：RN 自带 fetch 是否正常工作，遇到 TLS 证书问题怎么处理。

我在项目里预检时发现某些网络请求库在 OpenHarmony 上会有兼容问题，最后方案是中间件里统一走原生侧封装的请求模块。这个决策让后续所有业务网络请求都走了一条稳定链路，规避了大量环境差异问题。

4. 核心实操：从零写一个可用的 Redux 中间件

4.1 日志中间件：把 action 流完整记录下来

日志中间件是最容易上手的一类，也是排查问题的基础设施。我在 OpenHarmony 项目里写的第一版，要解决的三个问题：action 流完整可回溯、性能损耗可控、日志能在原生侧统一查看。

基础版本长这样：

const loggerMiddleware = store => next => action => { const prevState = store.getState() const startTime = Date.now() const result = next(action) const nextState = store.getState() const cost = Date.now() - startTime nativeLog({ type: action.type, payload: safeSerialize(action.payload), prevState: safeSerialize(prevState), nextState: safeSerialize(nextState), cost }) return result }

这里有个细节必须说明：next(action)之后立刻store.getState()，拿到的一定是 reducer 处理完的最新状态。因为 Redux 的 reducer 是同步执行的，中间件调用 next 的一瞬间，状态已经更新完成。

但safeSerialize这一步不能省。我在 OpenHarmony 上就遇到过状态里有不可序列化对象，导致日志桥接直接把应用搞崩溃的场面。具体实现可以用递归做序列化，遇到非纯数据就转成字符串：

function safeSerialize(obj) { if (obj === undefined) return '__undefined__' if (obj === null) return null if (typeof obj === 'function') return '__function__' if (obj instanceof Date) return obj.toISOString() if (Array.isArray(obj)) return obj.map(item => safeSerialize(item)) if (typeof obj === 'object') { const result = {} Object.keys(obj).forEach(key => { result[key] = safeSerialize(obj[key]) }) return result } return obj }

这个日志中间件在联调阶段帮了大忙。OpenHarmony 的调试器连接有时候不稳定，但原生日志面板是稳定的，所有 action 流转过程都能直接在 IDE 日志里看到。

4.2 异步请求中间件：处理加载态、竞态和错误

日志解决"看到发生了什么"，异步中间件解决"业务请求怎么和状态容器协作"。在 OpenHarmony 上跑业务，网络请求是绕不开的，而请求过程中的加载态、错误态、竞态，是状态管理最容易写烂的部分。

我实现的异步中间件思路是这样的：拦截 action 对象里带有异步描述字段的情况，自动处理 loading、success、failure 三种状态的派发，同时支持竞态取消。

const asyncMiddleware = store => next => action => { if (!action.async) { return next(action) } const { type, api, payload } = action const requestId = action.requestId || (Date.now() + Math.random().toString(36).slice(2)) store.dispatch({ type: `${type}_PENDING`, payload: { requestId } }) api(payload) .then(data => { store.dispatch({ type: `${type}_SUCCESS`, payload: { requestId, data } }) }) .catch(error => { store.dispatch({ type: `${type}_FAILURE`, payload: { requestId, error: safeSerialize(error) } }) }) return next({ type: 'ASYNC_DISPATCHED', payload: { reqId: requestId } }) }

用法在业务侧很简洁：

dispatch({ type: 'FETCH_USER_INFO', async: true, api: fetchUserInfo, payload: { userId: 123 } })

组件里只需要关注三种状态：pending 时显示 loading，success 时渲染数据，failure 时展示错误。

同时要注意竞态问题。用户快速切换页面，前面的请求还没返回，后面的请求已经发出，旧请求的响应回来覆盖了新数据，这是经典问题。上面的实现里每个请求都有 requestId，后续在 reducer 里可以根据 requestId 判断响应是否过期：

case 'FETCH_USER_INFO_SUCCESS': if (state.lastRequestId !== action.payload.requestId) { return state } return { ...state, data: action.payload.data }

4.3 桥接原生能力的中间件

这是 OpenHarmony 项目里最有平台特色的一部分。很多系统能力没有现成的 JS API，必须通过原生桥接模块调用，而中间件是把这类调用收纳统一的绝佳位置。

举个例子，假设业务需要读取设备型号来展示不同的 UI 适配逻辑。传统写法是在组件里直接调用原生模块，到处分布调用点。我选择把设备信息获得设计成 action，由中间件统一处理：

const deviceMiddleware = store => next => action => { if (action.type !== 'GET_DEVICE_INFO') { return next(action) } nativeDeviceModule.getDeviceInfo() .then(info => { store.dispatch({ type: 'GET_DEVICE_INFO_SUCCESS', payload: info }) }) .catch(error => { store.dispatch({ type: 'GET_DEVICE_INFO_FAILURE', payload: { error } }) }) return next({ type: 'GET_DEVICE_INFO_PENDING' }) }

组件里只需要dispatch({ type: 'GET_DEVICE_INFO' })，然后从 store 里取设备信息就行。这样做的好处非常明显：组件完全不感知原生模块的存在，后续如果原生实现变了，只要中间件内部改一下，业务代码不需要动。

我还用同样的思路封装了日志上报、文件读写、剪贴板等能力。时间久了，这套中间件集合实际上成为了 RN 业务层和 OpenHarmony 原生层之间的一个"能力适配层"。

4.4 中间件的组合与执行顺序调试

三个中间件都写好后，组合顺序需要仔细推敲。我的最终组合顺序是：

applyMiddleware( loggerMiddleware, asyncMiddleware, deviceMiddleware )

日志在最外层，可以看到所有投入 store 的 action；异步中间件处理带异步标记的请求；设备中间件只处理特定 type。这样职责分离，互不干扰。

调试时如果发现 action 没有触发期待的状态更新，可以先看日志中间件有没有记录到 action；没有记录，说明 dispatch 都没发生；记录了但 state 没变，说明问题在 reducer；如果 action 被拦截没往下走，那就是自定义中间件的过滤条件写错了。这套排查思路在真机调试时非常高效。

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

5.1 中间件不生效的经典原因

"我明明在 applyMiddleware 里挂了中间件，为什么它没跑？"这个问题的原因排序如下：

• 中间件没有诶包在 createStore 里，而是只传了 reducer。这个最好排查，看一眼 createStore 的第二个参数就知道了。
• store 是在 JS 入口文件里创建的，但组件实际连接的是另一个 store 实例。多入口构建时容易发生。
• 中间件的 filter 条件写错了，导致所有 action 都被 return next 短路跳过。比如把action.type !== 'XXX'写成action.type === 'XXX'。
• 原生侧和 JS 侧加载了不同的 bundle 版本。缓存导致用了旧的中间件代码。

在 OpenHarmony 上，第 4 条特别值得注意。JS bundle 的缓存策略和平台配置相关，改了代码不生效时，先清理缓存再重启，通常能解决。

5.2 日志中间件序列化崩溃

前面的 safeSerialize 就是血的教训基础上写的。OpenHarmony 的桥接层对数据格式要求更严格，传了无法序列化的对象到原生侧，轻则日志丢失，重则直接崩溃。

有一条通用规则：跨桥接的数据，必须是你完全可控的纯 JSON 数据。任何未知结构的对象，过桥之前先清洗。

5.3 Redux DevTools 连不上怎么办

在 Web 端用 Redux DevTools 是大家习惯的调试方式，OpenHarmony 上这个体验难以保证。我一开始也努力配 DevTools，最终放弃，转向了"日志中间件 + IDE 日志面板"这套组合。

虽然不如 DevTools 可视化直观，但 action 流转、状态变化、耗时信息都有，定位问题足够用了。如果你是团队负责人的角色，建议一开始就建立这种日志观测的规范，而不是依赖某个可能在 OpenHarmony 上不稳定的调试工具。

5.4 性能损耗与状态量膨胀

中间件链本身是有性能开销的。在实际项目中，每派发一个 action，日志中间件要序列化整个 state。如果 state 特别大、action 特别频繁，性能问题不可避免。

我的解法是分级日志策略。开发环境打开完整日志，发布环境只记录 action type 和耗时，不序列化大对象。这个开关通过环境变量或平台配置注入，中间件内部读取配置做判断。

5.5 常见问题速查表

6. 几个值得长期留意的工程化细节

6.1 多端条件编译与中间件隔离

如果你的业务是从原有的 iOS/Android RN 工程扩展过来，中间件必然存在跨端逻辑差异。我的建议是：统一的 action、统一的 reducer，中间件按平台拆成不同实现。界面和业务流程不用动，只需要在创建 store 时按平台选择中间件列表。

比如 iOS 上日志走系统的 os_log，Android 走 Logcat，OpenHarmony 走 IDE 原生日志。三套实现遵循同一个接口签名，在单独的 factory 文件里统一导出。这样做业务层完全无感。

6.2 版本锁定与依赖兼容

RN 版本、React 版本、Redux 版本、OpenHarmony 适配层版本，这几者之间有复杂的兼容关系。升级任何一个，都可能引发连锁反应。

在一个稳定的里程碑节点之后，建议把依赖版本用 lock 文件固定下来。新需求的开发在锁定版本上进行，定期统一升级，而不是零敲碎打地改。我吃过这个亏：手动升级了一个小依赖，结果整个原生工程编译不过，排查了两天才搞定。

6.3 最小可用中间件模板

最后发一个可以直接复制的中间件模板，作为后续写新中间件的起点。既保持了职责单一，又预留了能力扩展点：

const createApiMiddleware = (nativeModule, options = {}) => { const { timeout = 10000, retryCount = 1 } = options return store => next => action => { // 只处理本中间件关心的 action if (!action.meta || action.meta.middleware !== 'api') { return next(action) } // 组装请求配置 const request = { type: action.type, payload: action.payload, nativeCall: action.meta.call } // 超时控制 const timeoutPromise = new Promise((resolve, reject) => { setTimeout(() => reject(new Error('native call timeout')), timeout) }) // 实际调用 const callPromise = nativeModule.invoke(request) .then(data => { store.dispatch({ type: `${request.type}_SUCCESS`, payload: data }) }) .catch(error => { store.dispatch({ type: `${request.type}_FAILURE`, payload: { error: safeSerialize(error) } }) }) Promise.race([callPromise, timeoutPromise]) return next({ type: `${request.type}_PENDING` }) } }

写新中间件时，照着这个骨架改过滤条件、改异步处理逻辑、改原生调用方式，基本上不会出大问题。

回到标题本身再补一段话。React Native 在 OpenHarmony 上跑，本质上是把成熟的前端技术栈移植到一个新兴系统上，中间会经历阵痛，也会沉淀出不少平台特有的解决方案。Redux 中间件这个不起眼的扩展点，恰恰是承接这些方案的最佳位置。日志怎么打、异步怎么处理、原生能力怎么接入，这些跨端项目里的核心问题，都被中间件这个机制优雅收纳。实际跑过之后，我的体会是：不用苛求每一步都自动化、可视化，先把日志中间件做好，把状态流转看清楚，后面再逐步增加复杂度。很多开发者在 OpenHarmony 适配初期最容易犯的错误，是想着一次性把架构搭得特别完整，结果被底层环境的细节绊住，反而忽略了业务本身。我建议你从最小的中间件跑起来，让数据流先通，再围绕日志、异步、桥接三个点逐步丰富，这条路走起来最顺。