企业官网建设流程全解析

先说明一点，这篇不是给纯新手扫盲的“Hello World”，而是给那些已经决定在OpenHarmony设备上拥抱React Native生态、并且不想被重状态管理拖垮的团队看的。标题里提到的“Jotai原子派生状态”听着玄乎，但本质上解决的是跨端开发里最让人头疼的问题：业务逻辑怎么在原生能力和前端状态之间高效流转，又不把代码写成一团乱麻。

我用这套组合在鸿蒙化改造的项目里啃过硬骨头，今天把思路、实操和踩过的坑一次说清楚。

1. 为什么在OpenHarmony上选择React Native + Jotai

1.1 鸿蒙原生开发与RN跨端方案的博弈

OpenHarmony（以下简称OH）从诞生那天起，官方主推的开发语言就是ArkTS和ArkUI。但现实情况是，大部分互联网团队手里攒着一堆成熟的React Native业务代码，尤其是中后台、电商、工具类应用。让团队全员转学ArkTS不现实，把已有RN代码推倒重写更不现实。这里就出现了一个典型的博弈：原生体验和跨端效率到底怎么平衡。

我个人的判断是：在OH生态里做React Native适配，不是为了秀技术，而是为了业务存量。OH的RN适配方案目前已经有了可用的社区实现和官方支持方向，能让你把核心业务层继续用JS/TS编写，通过JSI（JavaScript Interface）与原生侧通信，同时UI层可以渐进式地走向ArkUI。但这套方案有一个暗坑，后面会专门讲。

这个组合的战略价值在于：业务逻辑层与UI渲染层解耦。Jotai作为状态管理，恰好卡在这个解耦点上。它不像Redux那样需要写一堆action和reducer模板，也不像MobX那样引入过多魔法，而是用原子（atom）这种极简概念，把状态切碎成可以独立派生、独立订阅的最小单元。在OH的多线程、多Ability环境下，这种细粒度状态管理反而更安全。

1.2 Jotai在跨端项目中的三大优势

Jotai的名字来自日语“状态”，它的核心API用一只手就数得过来：atom、useAtom、useAtomValue、useSetAtom。但恰恰是这种极简，让它特别适合React Native + OH这种双端环境。

第一，无Provider嵌套地狱。Redux要包Provider，MobX要包Provider，Zustand虽然不用全局Provider，但和React context的联动也需要额外处理。Jotai利用React 18的useSyncExternalStore，直接把store挂在模块级，组件树下不需要任何Provider包裹。在OH的RN适配层里，组件树的层数每多一层，跨桥通信的性能损耗就多一分，省掉Provider意义很大。

第二，原子级订阅。Jotai最核心的机制是：组件只订阅它用到的那一个atom。改了一个原子，只有依赖它的组件重渲染。在RN列表页、长表单这种场景里，性能差异是肉眼可见的。

第三，派生状态的天然表达。Jotai的派生atom可以直接写计算逻辑、异步逻辑、甚至组合多个原子。这在业务里意味着：筛选条件、排序规则、分页参数这些都可以拆成独立原子，再派生出最终的数据源。改条件自动重算数据，不需要手动派发事件去同步，心智负担极小。

2. 原子状态与派生状态的核心设计思路

2.1 把状态“切碎”的思维模式

很多从Redux转过来的同事最容易犯的错是：把一个页面的所有数据塞进一个巨大的atom对象里。比如：

const pageAtom = atom({ list: [], filters: { keyword: '', category: '', sort: '' }, loading: false, pageNum: 1, hasMore: true })

这种写法表面上用了Jotai，实际上是披着原子外衣的“大reducer”。一旦某个字段变，整个列表、筛选、loading全部联动重渲染，和用useState抱个大对象没本质区别。真正的原子化思维是让每个状态独立成一个原子，再通过派生关系把它们串起来：

const keywordAtom = atom('') const categoryAtom = atom<string[]>([]) const sortAtom = atom<'asc' | 'desc'>('desc') const pageNumAtom = atom(1) const filtersAtom = atom((get) => ({ keyword: get(keywordAtom), category: get(categoryAtom), sort: get(sortAtom) })) const listQueryAtom = atom(async (get) => { const filters = get(filtersAtom) const page = get(pageNumAtom) return fetchList(filters, page) })

这里体现的设计哲学是“状态单一、派生组合”。keyword、category、sort各自是独立来源，filters是它们的派生集合，listQuery又依赖filters。每层之间只是声明了关系，Jotai会在底层自动追踪依赖图，只有被依赖的原子变化时，派生原子才会重算。

2.2 派生原子：从“手动同步”到“自动计算”

传统状态管理里做联动逻辑，通常要写一堆监听器或者useEffect去手动setAnotherState。比如搜索框输入关键词，然后手动触发列表刷新，还要手动管理防抖。用Jotai的派生原子，这部分变成纯声明式：

const debouncedKeywordAtom = atom((get) => { const kw = get(keywordAtom) // 实际项目中这里可以配合一个delayAtom做真正的防抖 return kw.trim() }) const hasFilterAtom = atom((get) => { return get(debouncedKeywordAtom) !== '' || get(categoryAtom).length > 0 })

当keywordAtom变化时，debouncedKeywordAtom自动重算，hasFilterAtom跟着自动更新。你不需要在任何地方写“当keyword变化时，更新hasFilter”。这就是派生状态的价值：状态之间的同步逻辑被框架接管，你只负责声明业务关系。

这个思路在React Native里特别受用，因为RN的setState是异步批处理的，一旦涉及多状态联动，手动同步很容易出现“这次set还没生效，另一个set已经读到了旧值”的竞态。Jotai的get机制保证了一次派生计算里读到的所有原子值都是同一帧的一致快照，从机制上消灭了一类bug。

2.3 异步派生：处理接口请求的优雅姿势

React Native项目里绕不开异步数据。用Jotai处理异步派生，比useEffect + useState的组合干净得多：

const listStateAtom = atom(async (get) => { const filters = get(filtersAtom) const page = get(pageNumAtom) const res = await fetchList(filters, page) return res.data }) // 在组件里 const listState = useAtomValue(listStateAtom)

就这么简单。listStateAtom是异步的，Jotai会自动把Promise包装进加载状态,组件里直接解构：

const [listState] = useAtom(listStateAtom) // listState 可能是 { data, loading, error } 的联合类型

这在React Native + OH环境里还有额外好处：异步原子天然兼容OH侧的异步Ability回调。比如你在RN里调一个原生模块做设备信息采集，这个回调本身就是Promise风格的，直接喂给派生原子，UI层无感。

3. 在OpenHarmony工程里集成Jotai的完整实操

3.1 工程初始化与依赖安装

OpenHarmony上跑React Native，工程形态和普通RN项目略有区别。你需要先有一个OH原生工程，然后通过RN的OH适配层把JS bundle挂载上去。我这里假设你已经有了一个能跑通的RN基础工程，只讲Jotai集成部分。

安装依赖一条命令：

npm install jotai

就这么简单，不需要额外配置babel插件，不需要修改metro配置。Jotai能在RN上无缝运行，因为它只依赖React的并发特性和useSyncExternalStore，这两个在RN新架构（Fabric）下都是原生支持的。如果你的项目还在旧架构（Paper），只要React版本在18以上，同样没问题。

3.2 Provider到底要不要挂

上面说过Jotai不需要Provider。但实际项目中有一个例外：如果你要配合Jotai的调试工具（比如Redux DevTools扩展），或者要用到Jotai的useAtomProvider定制Scope，才需要手动挂Provider。否则，真的可以裸用。

// App.tsx 根组件 import { useAtom } from 'jotai' import { countAtom } from './store/counter' export default function App() { const [count] = useAtom(countAtom) // ... }

这个根组件不需要任何包裹。这对于OH场景很重要，因为OH的Ability生命周期和RN的根组件挂载时机并不完全同步，少一层Provider就少一个“容器组件还没挂载但store已经被访问”的边界问题。

3.3 原生模块通信与原子绑定的桥接模式

OH的RN适配方案里，原生模块的通信方式和标准RN不完全一样。常用的方式是声明一个原生能力接口，通过TurboModule（新架构）或NativeModules（旧架构）暴露给JS侧。Jotai在这里的妙用是：把原生模块的返回值直接定义为原子，让UI层订阅这个原子的变化。

// 原生模块桥接层 import { NativeModules } from 'react-native' const { DeviceInfoModule } = NativeModules // 定义原子 const deviceInfoAtom = atom(async () => { const info = await DeviceInfoModule.getDeviceInfo() return info }) // 在业务组件里 const deviceInfo = useAtomValue(deviceInfoAtom)

这里要注意的是：OH侧的原生模块调用是异步的，而且某些能力（比如获取系统版本、读取设备唯一标识）可能在不同的Ability生命周期里表现不同。把这类调用做成异步派生原子后，组件甚至可以在useEffect里重复调用setAtom刷新，原子内会自然处理竞态。

3.4 与OH侧Ability状态同步的实战写法

OH应用有UIAbility、ServiceAbility等概念。RN页面通常跑在UIAbility里，但如果你的业务需要从ServiceAbility拿数据（比如后台任务进度），就需要把数据同步进JS状态。

我的做法是：在入口处定义一组syncAtom，专门接收原生侧通过事件通道抛过来的数据：

import { atom } from 'jotai' import { DeviceEventEmitter } from 'react-native' const taskProgressAtom = atom(0) export function initNativeEventBridge() { DeviceEventEmitter.addListener('onTaskProgress', (progress: number) => { // 事件回调里直接set原子，UI自动更新 taskProgressAtom.init // 这里注意，不要手动set，见下面说明 }) }

这里有个容易踩的坑：Jotai的atom在默认情况下，如果不使用useAtom，外部只能通过store.set来修改。直接在模块级调用useSetAtom是不行的，因为那需要React组件上下文。正确的做法是用Jotai导出的store实例：

import { createStore } from 'jotai' const myStore = createStore() const taskProgressAtom = atom(0) // 在事件回调里 myStore.set(taskProgressAtom, progress)

这也是Jotai 2.x版本的一个重要特性：store实例外部化，可以在任何JS上下文里操作原子，不限于React组件。对于RN + OH这种需要处理大量原生事件回调的场景，这是必须掌握的用法。

4. 启动白屏问题的排查与状态加载策略

4.1 白屏的根源：bundle加载与状态初始化时序

搜“react native 启动白屏”能看到一堆讨论。在OH平台上，这个问题更特殊。OH的RN适配层在加载JS bundle时，如果UIAbility的onWindowStageCreate阶段就尝试渲染RN根组件，而此时bundle还没解析完成，就会出现白屏。

结合Jotai的状态初始化，这里有个隐蔽的坑：异步派生原子在首次渲染时如果依赖的Promise还没resolve，组件会先返回loading状态或undefined。如果你的根组件直接渲染异步派生值而不做兜底，白屏就会被误认为“状态还没加载完”。

实操建议是：在RN根组件挂载前，先启动一个“预加载原子”：

const bootstrapReadyAtom = atom(false) export async function bootstrap() { // 并行执行原生能力初始化、缓存读取、登录态检查等 await Promise.all([ initNativeModule(), loadCache(), checkLogin() ]) myStore.set(bootstrapReadyAtom, true) }

在index.js入口文件的最顶层调用bootstrap，等bootstrapReadyAtom变成true后再渲染真正的RootComponent。这是一种“先初始化状态，再挂UI”的策略，有效避免白屏期间UI层读不到数据导致的渲染残缺。

4.2 白屏排查的五个检查点

根据我在OH设备上的实测，白屏排查按下面顺序查，命中率最高：

1. bundle加载是否超时。OH的RN适配层加载本地bundle一般不会超时，但如果你用了远程bundle（debug模式），要确认OH设备和后端服务器的网络连通性。查看Log标签为“RNOH”的日志，能直接看到bundle加载状态。

2. 根组件是否同步抛错。Jotai的异步原子如果在初始化阶段就reject，组件拿到的state是error状态。如果没有在组件里处理error分支，渲染会崩溃或白屏。检查方式：在根组件里加一个ErrorBoundary，把错误抛到原生侧日志里。

3. 原生模块是否提前调用。如果bootstrap阶段调用了还没注册的原生模块，调用会失败，Promise一直pending，bootstrapReadyAtom永远变不成true。

4. FPS是否过低导致渲染看起来像白屏。OH的RN适配层在GPU渲染部分目前优化还不完善，如果你的页面首帧包含了大量复杂组件，可能出现“渲染太慢看起来像白屏”的错觉。用react-native-performance或直接在Dev Menu里看帧率，区分是逻辑白屏还是渲染性能白屏。

5. 是否误用了React StrictMode。StrictMode会让组件渲染两次，如果结合Jotai的异步派生原子，可能导致首次渲染的Promise状态被你一不小心清掉了。

4.3 用Jotai管理bootstrap状态的最佳实践

在bootstrap阶段，我习惯把状态机拆成多个原子，直观而且可控：

const initStatusAtom = atom<'idle' | 'loading' | 'ready' | 'error'>('idle') const initErrorAtom = atom<string | null>(null) const appReadyAtom = atom((get) => { return get(initStatusAtom) === 'ready' })

然后在根组件里：

const AppRoot = () => { const appReady = useAtomValue(appReadyAtom) if (!appReady) return <SplashScreen /> return <MainApp /> }

这样做的价值在于，如果初始化失败，可以单独做些降级渲染。比如某些不是致命错误的问题（如缓存读取失败），可以设一个partialReadyAtom，让应用先以只读模式进入，而不是卡在启动页。这种细粒度控制在纯Redux方案里要写很多样板，Jotai里就是多声明两个原子的事。

5. 派生状态在业务场景中的落地与性能调优

5.1 场景一：筛选联动列表（搜索+分类+排序）

这是典型的多状态联动场景。电商App的一个商品列表页，顶部搜索框、分类Tag栏、排序按钮都是独立交互，但它们共同决定列表数据。用Jotai的实现：

const searchKeywordAtom = atom('') const selectedCategoryAtom = atom('all') const sortTypeAtom = atom('default') const visibleProductListAtom = atom(async (get) => { const keyword = get(searchKeywordAtom) const category = get(selectedCategoryAtom) const sort = get(sortTypeAtom) const allProducts = get(allProductsAtom) // 同步过滤 + 排序 const filtered = allProducts.filter(p => p.name.includes(keyword) && (category === 'all' || p.category === category) ) if (sort === 'priceAsc') filtered.sort((a, b) => a.price - b.price) return filtered })

这个派生原子做了三件事：读取三个输入原子、过滤器、排序器。任何输入变化都会自动重算出新列表。在React Native里，你不需要在每次onChange时手动去setList，也不需要防抖处理，因为派生是同步的、声明式的。

关于性能：如果商品数量很大（几千条），每次输入变化都重新filter也不是最优的。这时候可以考虑拆出memoizedAtom，配合Jotai的atomWithMemo或者直接用外部工具如reselect。不过项目初期，先保证逻辑清晰远比提前优化重要。

5.2 场景二：购物车数量与选中状态的原子联动

购物车最麻烦的逻辑是：单个商品数量变化 -> 小计变化 -> 全选状态变化 -> 总价变化 -> 底部栏结算按钮是否可用。这个依赖链条又长又容易在手动同步时出bug。

用Jotai拆解：

type CartItem = { id: string; price: number; count: number; selected: boolean } const cartItemsAtom = atom<CartItem[]>([]) const selectedItemsAtom = atom((get) => { return get(cartItemsAtom).filter(item => item.selected) }) const totalPriceAtom = atom((get) => { const selected = get(selectedItemsAtom) return selected.reduce((sum, item) => sum + item.price * item.count, 0) }) const allSelectedAtom = atom( (get) => { const items = get(cartItemsAtom) return items.length > 0 && items.every(item => item.selected) }, (get, set, newVal: boolean) => { // 写入原子：全选/取消全选 const items = get(cartItemsAtom) set(cartItemsAtom, items.map(item => ({ ...item, selected: newVal }))) } )

注意最后这个atom的写法：一个atom可以同时有读函数和写函数。读函数是派生计算，写函数则定义了“当设置全选状态时，如何影响其他原子”。这比在组件里dispatch一个复杂的action清晰多了。

在React Native里，这个链路还有个优化点：把totalPriceAtom的计算用useMemo包一下，然后组件里用useAtomValue订阅。Jotai底层会做相等性比较，如果totalPrice算出来的值和上次一样，不会触发重渲染。这直接避免了购物车界面随商品勾选变化而整体闪烁的问题。

5.3 性能调优：避免不必要的重渲染

Jotai的重渲染优化依赖原子值之间的引用相等性。派生原子每次计算返回的都是新引用（比如新的filtered数组），这会导致依赖它的组件每次都重渲染。如果这个组件是列表本身，性能隐患就来了。

我的实践经验是：把列表拆成“数据原子”和“UI状态原子”两层。列表只订阅数据原子，而UI相关的滚动位置、当前选中项ID这些高频变化的状态独立成原子：

const listDataAtom = atom((get) => get(visibleProductListAtom)) const scrollPositionAtom = atom(0) const selectedProductIdAtom = atom<string | null>(null)

selectedProductIdAtom和scrollPositionAtom的变化不会触发listDataAtom重算。反过来，listDataAtom变化时，scrollPosition不会动，列表不会跳回顶部。这在Redux时代需要自己实现selector缓存，Jotai天然就是这种粒度。

还有一个容易忽略的点：派生原子内部的异步函数小心闭包陷阱。比如：

const listAtom = atom(async (get) => { const page = get(pageNumAtom) // 这里不能用外部变量，要用get来依赖pageNumAtom const data = await fetchList({ page }) return data })

如果你在派生函数里直接读外部变量而非通过get读取，Jotai的依赖追踪就失效了，这个原子不会在外部变量变化时自动重算。这个坑我踩过好多次，排查起来特别隐蔽，因为逻辑看起来没毛病，就是页面不刷新。

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

6.1 问题速查表与分析

关于表格最后一条，防抖在Jotai里可以通过组合实现：

import { atom } from 'jotai' function atomWithDebounce<T>(initialValue: T, delay: number) { const baseAtom = atom(initialValue) const debouncedAtom = atom(initialValue) // 利用Jotai的写函数拦截，实现防抖 const writeAtom = atom( (get) => get(debouncedAtom), (_get, set, newValue: T) => { set(baseAtom, newValue) setTimeout(() => set(debouncedAtom, newValue), delay) } ) return writeAtom }

不过这个方案有bug，因为每次set都会启动一个新定时器，旧定时器没清。工业级方案还得用setTimeout的返回值管理或者引入jotai-effect。我现在项目里直接用useAtomValue配合rxjs的debounceTime做的，好奇的可以翻我的历史文章。

6.2 OH平台特有的状态管理坑

OH的调度模型和Android/iOS不太一样。RN在OH上的JS线程跑在ArkTS的TaskPool里，这意味着状态更新的时序在某些边界场景下可能和标准RN不同。我遇到过一个诡异问题：在页面A设置了一个atom的值，切到页面B后读取，发现读到的还是旧值。

排查后发现，问题不在Jotai，而在OH的Ability生命周期里两个页面跑在不同的JSContext上。解决方案是在页面切换时通过全局事件桥同步状态，或者把需要跨页面共享的状态提升到UA级别的全局store里，而不是依赖RN的页面栈保留。

6.3 调试技巧：可视化查看原子状态

Jotai官方提供了jotai-devtools，但它在RN上的支持还不完善。我在OH工程里用的是最朴素的办法：在SplashScreen组件里临时渲染一个debug面板，订阅关键原子，把它们的值显示在屏幕上。这个调试面板只在DEV环境开启：

import { useAtomValue } from 'jotai' function DebugPanel() { const appReady = useAtomValue(appReadyAtom) const pageNum = useAtomValue(pageNumAtom) // 实际项目中可以遍历一个atom列表，统一显示 return ( <View style={{ position: 'absolute', top: 100, backgroundColor: 'red' }}> <Text>{`ready: ${appReady}`}</Text> <Text>{`page: ${pageNum}`}</Text> </View> ) }

比Redux DevTools的远程调试轻量多了，而且不依赖网络连接。在OH设备上，通过hdc log查看console日志不方便，直接在屏幕上渲染DebugPanel反而最直观。

7. 扩展思路：Jotai + OH原生能力的深度联动

如果只是用Jotai管理RN侧的UI状态，其实没有完全发挥这套架构的威力。我更推荐把OH的特色能力（分布式数据、传感器、后台任务）桥接成原子状态，让业务代码像使用普通状态一样使用系统能力。

比如分布式数据管理（DistributedData）可以抽象成：

const remoteDeviceStatusAtom = atom<Record<string, boolean>>({}) const distributedSyncAtom = atom( (get) => get(remoteDeviceStatusAtom), async (_get, set, deviceId: string) => { const status = await DistributedData.getStatus(deviceId) set(remoteDeviceStatusAtom, (prev) => ({ ...prev, [deviceId]: status })) } )

这样鸿蒙特有的“跨设备流转”能力就能以一种非常优雅的方式融入RN业务代码。你在组件里只需要useAtom，然后在合适的时机set，底层的分布式数据同步逻辑被完全封装在原子背后。

这个思路本质上是在做“领域模型驱动”的状态管理。原子不再只是UI状态容器，而是领域能力的统一入口。对于要同时维护OH原生能力和RN业务层的团队来说，这种架构能有效减少两层之间的胶水代码量，让开发者把注意力放回业务本身。

关于这套方案后续还能怎么扩展，我的想法是：随着OH的RN适配层逐渐成熟，Jotai在里面的价值会越来越大——因为跨端状态管理最怕的就是“双份逻辑、双份状态”，而原子派生模型天然支持把“一份真相”放在最合适的地方。如果你也开始在OH上做RN改造，建议花两天时间把Jotai的派生思路摸透，后面省下的调试时间一定远超这两天。