企业官网建设流程全解析

先说说这段迁移经历。团队要把已有的React Native应用搬到鸿蒙设备上，最开始我们想的很简单：代码大部分能复用，改改配置、跑通桥接就行。结果真到联调才发现，第一个卡住的不是原生模块，不是页面跳转，而是状态管理。

项目里原本用的是Redux Toolkit加MobX混着用，在iOS和Android上跑了快两年没出过什么大问题。可同一套代码放进鸿蒙侧的RN运行环境里，问题开始冒出来了：跨线程通信后状态更新经常慢半拍，页面已经切过去了，数据还是旧的；MobX的响应式代理在某些真机上会莫名失效，页面不报错，只是不刷新。排查一圈下来，团队里有人提了一句：“要不试试Jotai？那个是原子状态管理，模型足够小，说不定在鸿蒙上反而更稳。”于是就有了这篇文章。

Jotai这个词在日语里是“状态”的意思，它提供的是一套基于原子（atom）的状态管理方案：把每个独立的状态拆成最小单位，用React自身的调度机制驱动更新。写法和心智负担都比Redux轻得多，也不依赖MobX那种深层Proxy魔法。实际跑下来，它确实成了我们鸿蒙适配过程中最省心的部分之一。这篇文章就从选型对比、核心概念、接入步骤、真机踩坑到目录设计，完整聊聊我们是怎么在RN鸿蒙工程里落地这套原子状态管理的。

1. 为什么我在鸿蒙适配里把状态管理换成了Jotai

先交代一下背景。我们的React Native应用要跑上鸿蒙设备，走的是社区主流的鸿蒙侧RN适配层方案。架构上JS代码跑在鸿蒙提供的JS运行时里，UI渲染和原生能力通过桥接层跟ArkTS侧通信，整体可以理解为“JS业务逻辑 + 原生桥接 + ArkTS容器”的组合。

这种架构下，状态管理库跑在JS侧，但它的每次setState最终要穿过桥接、触发React Reconciler、再驱动原生视图更新。链路比纯Android/iOS环境更长，而且鸿蒙侧的RN运行时对JS引擎做了一定限制和裁剪。很多在Android上跑得飞快的库，到这里就会暴露兼容性问题。

1.1 Redux、MobX和Jotai在鸿蒙侧的真实表现

我们先看当时在鸿蒙真机上遇到的问题。

Redux那边，问题主要集中在异步时序上。业务里大量使用了Redux Toolkit的createAsyncThunk，在Android上一切正常。鸿蒙侧联调时，dispatch一个异步action后，pending和fulfilled状态有时候会乱序，尤其是快速切换页面时，可能出现“先发的请求后返回，把新状态覆盖成旧状态”的情况。另外Redux的connect高阶组件在鸿蒙的引擎下需要额外做batchedUpdates适配，否则连续dispatch多次时，中间状态会被渲染到界面上，造成明显闪烁。

MobX的问题更隐蔽。MobX的核心是Proxy响应式代理，通过拦截对象属性访问来收集依赖。鸿蒙侧RN运行时对Proxy的支持虽然存在，但在某些系统版本和机型组合下，代理失效的偶发率不低。表现就是数据确实改了，组件不重渲染。这类问题最难排查，因为它不像报错那么明显，而是“偶尔不动、刷新一下又好了”的诡异状态。

反观Jotai，它的实现思路完全不同——状态是用atom()创建出的普通对象，依赖关系通过原子的读取路径来追踪，底层使用React的useSyncExternalStore与组件同步。整个过程没有任何全局事件总线，也不需要多层Provider嵌套，跨桥接链路时状态流转路径很短。实际用下来的第一感觉就是：“这个东西小到没有地方可以出问题。”

1.2 三个方案的核心差异对比

为了方便选型，我做了一张表格，记录我们在鸿蒙真机上对三个方案的实际观察。

这不是说Redux或MobX“不好”，而是它们的复杂度在鸿蒙RN运行环境里会被放大。Jotai的优势在于够简单：没有action、没有reducer、没有复杂的中间件，一个atom就是一个状态，useAtom钩子直接拿到值和更新函数。它的设计哲学是“状态就应该尽可能靠近使用它的组件”，这种思路跟我们适配鸿蒙时“减少跨层依赖、降低链路复杂度”的目标高度一致。

2. Jotai的原子模型：从atom到useAtom的核心机制

聊完了选型，接下来把Jotai最核心的几个概念拆开讲清楚。理解这些，后面在鸿蒙上写业务时才能心里有底，遇到问题也知道往哪个方向排查。

2.1 什么是“原子”

atom的概念可以理解成一个状态的最小单元。它不像Redux那样集中在一个Store里，也不像MobX那样把整个对象变成响应式。每个atom就是一个独立的、可订阅的“状态格子”，创建方式极其简单：

import { atom } from 'jotai'; // 基础原子：保存一个数字 const countAtom = atom(0); // 派生原子：依赖其他原子，自动计算 const doubleCountAtom = atom((get) => get(countAtom) * 2); // 可写派生原子：既能读，也能更新来源原子 const incrementAtom = atom( (get) => get(countAtom), (get, set) => set(countAtom, get(countAtom) + 1) );

基础原子保存原始值，派生原子根据依赖自动计算。它们之间的关系是一张有向图，Jotai内部会维护这张依赖图，任何上游原子变化时，下游消费它的组件都会自动重渲染。

用生活化的类比来解释：把atom想象成一个Excel单元格。countAtom是A1单元格，值写死成0。doubleCountAtom是B1单元格，公式是=A1*2。A1变了，B1自动跟着变。Jotai做的就是实时监控A1有没有被修改，一旦修改就通知所有能看到B1的人刷新。

2.2 useAtom：连接状态和组件

在组件里读写原子，使用的是useAtom钩子：

import { useAtom } from 'jotai'; import { View, Text, Button } from 'react-native'; function Counter() { const [count, setCount] = useAtom(countAtom); return ( <View> <Text>当前值：{count}</Text> <Button title="+1" onPress={() => setCount(count + 1)} /> </View> ); }

useAtom返回一个元组，格式跟useState完全一样。count是当前值，setCount是更新函数。更新函数既可以接收新值，也可以接收函数式的更新逻辑：

setCount((prev) => prev + 1);

这种设计与React原生状态API对齐，学习成本几乎为零。在鸿蒙侧RN环境里，组件点击按钮、状态变化、UI刷新这条链路短，不容易出现Android上那种“这边状态变了、那边UI还没反应”的错位感。

2.3 派生原子和异步原子在鸿蒙侧的应用

实际业务里我们大量使用了派生原子。一个典型的场景是购物车角标：页面头部显示商品总数，购物车列表页显示明细。两者其实共享同一个基础原子，但展示逻辑不同。

// store/cart.ts import { atom } from 'jotai'; export interface CartItem { id: string; name: string; price: number; count: number; } export const cartItemsAtom = atom<CartItem[]>([]); // 派生原子：总数量 export const cartTotalCountAtom = atom((get) => get(cartItemsAtom).reduce((total, item) => total + item.count, 0) ); // 派生原子：总价 export const cartTotalPriceAtom = atom((get) => get(cartItemsAtom).reduce( (total, item) => total + item.price * item.count, 0 ) );

页面头部只订阅cartTotalCountAtom，列表页订阅cartItemsAtom。上游cartItemsAtom变化时，两个派生原子的依赖者都会被精确通知，而不是像集中式Store那样整个页面全量刷新。

异步原子则用来处理接口数据：

import { atom } from 'jotai'; export interface UserInfo { id: string; name: string; avatar: string; } export const userIdAtom = atom<string | null>(null); export const userInfoAtom = atom<UserInfo | null>(async (get) => { const id = get(userIdAtom); if (!id) return null; const response = await fetch(`/api/user/${id}`); return response.json(); });

这个写法在Web端很简洁，但在鸿蒙真机上我们踩了坑，第三节会专门讲。

2.4 为什么Jotai的依赖追踪更适合受限JS引擎

再补充一个细节。MobX的依赖追踪依赖Proxy拦截，需要在对象属性访问层面做大量hook操作。鸿蒙侧RN运行时的JS引擎对Proxy的支持并非全场景无死角，尤其在对象被多次封装、跨桥接传值后，拦截链路容易断掉。

Jotai虽然内部也有读取追踪，但它的追踪是建立在函数调用路径上的：派生原子通过get()函数读取上游值时，Jotai记录依赖关系；组件通过useAtom读取原子值时，依赖关系被React的useSyncExternalStore捕获。整个过程不涉及对象代理，因此对引擎特性依赖更少，在资源受限的鸿蒙运行环境里更稳。

3. 从零接入：在RN鸿蒙工程里配好Jotai的完整路径

这一节讲具体接入步骤。我们的工程是标准的React Native工程，鸿蒙侧通过适配层把RN页面挂载到原生容器里，这里会涉及一些鸿蒙侧配置，但核心逻辑都在JS侧。

3.1 环境准备与安装

环境方面，我们使用的RN版本是0.7x，鸿蒙SDK是较新的API版本，IDE使用鸿蒙官方提供的开发工具。Jotai本身不挑版本，也不需要额外配置Babel插件，这是它在鸿蒙工程里最大的优势之一。很多状态管理库在鸿蒙构建链路上需要额外编译插件，走不通就得自己改构建配置，而Jotai装完就能用。

安装命令：

npm install jotai

或者用yarn：

yarn add jotai

安装完成后不需要在入口文件做Provider包裹。Jotai默认使用全局Store，这是它区别于Redux的关键一点。如果你希望某个子树的状态隔离，可以用Provider包裹：

import { Provider } from 'jotai'; import { ReactNode } from 'react'; export function AppProvider({ children }: { children: ReactNode }) { return <Provider>{children}</Provider>; }

默认情况下，所有atom共享同一个全局Store，页面间天然互通，省去了Redux那一套connect或hooks selector的黏合代码。

3.2 鸿蒙侧工程的最小配置

在鸿蒙工程里加载RN页面，通常需要先在ArkTS侧创建一个原生组件容器，再通过桥接加载JS侧入口。这一步每个适配方案的写法略有差异，但大致流程是固定的：

1. 在鸿蒙工程里创建Fragment或Page，承载RN渲染视图；
2. 初始化RN运行时环境，注册JS入口文件；
3. 通过桥接把RN生成的视图添加到原生布局中。

JS侧入口文件保持正常写法即可：

import { AppRegistry } from 'react-native'; import { App } from './App'; import { name as appName } from './app.json'; AppRegistry.registerComponent(appName, () => App);

Jotai不参与原生桥接过程，它只运行在JS侧。这一点很重要——我们不需要为它编写任何原生Module，也不需要关心ArkTS侧的依赖注入。状态管理完全收敛在JS层，跨端复用成本很低。

3.3 第一个Jotai原子在鸿蒙页面上的运行链路

下面是一个最小可运行示例，包含状态定义、组件消费和更新：

// App.tsx import React from 'react'; import { View, Text, Button } from 'react-native'; import { atom, useAtom } from 'jotai'; const greetingAtom = atom('欢迎来到鸿蒙'); function Greeting() { const [greeting, setGreeting] = useAtom(greetingAtom); return ( <View style={{ padding: 20 }}> <Text>{greeting}</Text> <Button title="更新消息" onPress={() => setGreeting('状态更新成功')} /> </View> ); } export function App() { return <Greeting />; }

这段代码跑通后，你就已经完成了Jotai在RN鸿蒙工程里的最小接入。点击按钮时，状态更新、组件重渲染、UI刷新，整个过程不涉及额外配置。如果这一步遇到问题，优先检查RN运行时是否能正常加载JS，以及桥接是否通——跟Jotai本身关系不大。

3.4 接入过程中的几个注意点

实际接入时，有几个容易被忽略的细节：

• 不要重复创建atom。如果某个atom在组件内部用useMemo创建，卸载重挂载后会丢失状态。正确方式是把atom定义在组件外部或模块顶层。
• 全局Store默认持久存在于JS运行时生命周期里。页面关闭不代表store销毁，除非你显式清理。如果业务要求页面级状态随页面销毁，用Provider包一层做隔离。
• Jotai在鸿蒙上跑的是微任务调度，连续多次setAtom时，React会自动批量更新。不需要像Redux那样手动做batchedUpdates适配。

4. 真机实测踩坑：异步原子不触发Suspense和组件内定义atom的状态抖动

这部分是全文最有价值的一节。我们在鸿蒙真机上踩了两个跟Jotai相关的坑，排查过程走了不少弯路，讲清楚能帮你省好几个小时。

4.1 异步原子 + Suspense 在鸿蒙上不显示降级UI

第一个坑出现在异步原子配合React Suspense的场景。

业务需求是用户进入个人中心页时，先展示骨架屏，接口返回后展示完整用户信息。按照Jotai官方文档推荐，我们使用了异步原子配合Suspense方案：

// 官方推荐写法之一 import { Suspense, useEffect } from 'react'; import { View, Text } from 'react-native'; import { useAtom } from 'jotai'; import { userInfoAtom } from '../stores/user'; function UserProfile() { const [userInfo] = useAtom(userInfoAtom); return <Text>{userInfo?.name}</Text>; } export function ProfileScreen() { return ( <Suspense fallback={<Text>加载中...</Text>}> <UserProfile /> </Suspense> ); }

这段代码在Web端和Android上都能正常显示“加载中...”的fallback。到了鸿蒙真机上，表现诡异：页面白屏，fallback不出来，数据其实已经加载完了，界面却一直停在那里。控制台也没有任何报错，看起来像是Suspense被“卡住”了。

排查过程我们分了几步：

第一步，确认异步原子本身是否正常。把Suspense去掉，改成手动读取状态并打印日志，发现userInfoAtom的promise确实resolve了，数据能拿到。

第二步，单独测试Suspense基础能力。写了一个永远不会resolve的异步原子，希望它能触发fallback，结果鸿蒙上依然白屏。到这里基本锁定了问题：鸿蒙侧RN运行时下，React的Suspense抛出的“挂起”信号没有被正确传递到渲染器层面，导致fallback机制失效。

第三步，查询社区资料发现，当时鸿蒙适配层对React并发特性（包括Suspense）的支持存在裁剪。React Native的Fabric渲染器在鸿蒙侧的实现并未完整支持所有并发渲染路径，Suspense的降级显示依赖这个机制，因此表现异常。

最终的解决方案是绕开Suspense，使用Jotai的loadable工具手动管理加载态：

import { atom, useAtom } from 'jotai'; import { loadable } from 'jotai/utils'; import { View, Text, ActivityIndicator } from 'react-native'; // 异步原子 const userInfoAtom = atom(async () => { const response = await fetch('/api/user/profile'); return response.json(); }); // loadable包装，将异步状态转为普通值 const userInfoLoadableAtom = loadable(userInfoAtom); function UserProfile() { const [userInfoLoadable] = useAtom(userInfoLoadableAtom); return ( <View style={{ padding: 20 }}> {userInfoLoadable.state === 'loading' && ( <ActivityIndicator size="large" /> )} {userInfoLoadable.state === 'hasData' && ( <Text>{userInfoLoadable.data?.name}</Text> )} {userInfoLoadable.state === 'hasError' && ( <Text>加载失败</Text> )} </View> ); }

loadable会把异步原子包装成一个同步状态对象，包含loading、hasData、hasError三种状态。这样不用Suspense也能完整表达加载、成功、失败三种UI分支。改动量不大，但在鸿蒙真机上的表现立刻恢复正常。这是我建议所有鸿蒙RN项目直接采用loadable方式处理异步状态的原因——不仅绕开了Suspense兼容问题，代码可读性也更明确。

4.2 组件内定义原子导致列表页状态抖动

第二个坑更难察觉。现象是：一个商品列表页，页面结构是FlatList + 多选功能。勾选某个商品后，列表会闪一下，滚动位置跳动，有时勾选状态还会自己消失。

排查链路是这样的：

第一步，怀疑是FlatList的extraData问题。检查后发现extraData传入的是派生原子计算出的数组，每次setState都会生成新引用，FlatList重渲染属正常行为，但状态不应该丢失。

第二步，怀疑是useCallback依赖问题。检查后发现不是。

第三步，打印日志追踪勾选状态。发现每次勾选时，对应商品项的选中原子被重置成了初始值。这里的信息量就大了——哪个地方会重置原子？

最终定位到问题代码：

function ProductItem({ product }: { product: Product }) { // 错误示例：在组件内部创建原子 const selectedAtom = useMemo( () => atom(false), [product.id] ); const [selected, setSelected] = useAtom(selectedAtom); return ( <TouchableOpacity onPress={() => setSelected(!selected)}> <Text>{product.name}</Text> </TouchableOpacity> ); }

看似合理，用useMemo缓存了atom实例。问题是：当FlatList滚动、item卸载重挂载，或者父组件setState导致ProductItem重新渲染时，useMemo的依赖如果没有变化，缓存应该还在。但实际场景中，product.id如果来自列表接口且每次刷新后是同一个值，按理不会重置。

进一步排查发现，FlatList在鸿蒙上的滑动回收机制比Android更激进。item组件会被频繁卸载和重挂载，useMemo的缓存是否保留取决于组件实例是否保留。一旦组件实例被销毁，useMemo重新执行，atom(false)就被重新创建，勾选状态自然丢失。这在Android上偶发，但在鸿蒙侧回收策略更积极，触发概率极高。

解决方案很简单：把每个商品项的选中状态放进一个模块级的atomFamily里。

import { atomFamily } from 'jotai/utils'; // 模块顶层定义atomFamily，按商品ID独立管理选中状态 export const productSelectedAtom = atomFamily((productId: string) => atom(false) );

组件内只需要：

function ProductItem({ product }: { product: Product }) { const [selected, setSelected] = useAtom(productSelectedAtom(product.id)); return ( <TouchableOpacity onPress={() => setSelected(!selected)}> <Text>{product.name}</Text> </TouchableOpacity> ); }

atomFamily会为每个product.id创建并缓存独立的原子，无论组件怎么卸载重挂载，状态都保存在全局Store里，不会再丢失。这个坑的启示是：Jotai虽然允许在组件附近定义原子，但为了适配鸿蒙激进的组件回收策略，全局性的、依赖业务ID的状态一定要用模块级atomFamily管理。

5. 从单个原子到状态目录：鸿蒙RN项目的Jotai模块化实践

单组件用Jotai很简单，但一个大型RN鸿蒙项目要跑得稳，得在工程层面做好目录规划和状态职责划分。这里分享我们最终沉淀下来的实践方案。

5.1 状态目录的推荐结构

我们的业务状态按域拆分，每个域一个文件，统一从index.ts导出。

src/ ├── stores/ │ ├── index.ts │ ├── auth.ts │ ├── cart.ts │ ├── product.ts │ └── settings.ts ├── screens/ ├── components/ └── App.tsx

以auth.ts为例：

// stores/auth.ts import { atom } from 'jotai'; import { atomWithStorage } from 'jotai/utils'; export interface AuthState { token: string | null; userId: string | null; nickname: string; } export const authStateAtom = atomWithStorage<AuthState>( 'auth-state', { token: null, userId: null, nickname: '', }, createAsyncStorage() );

index.ts里统一导出：

// stores/index.ts export * from './auth'; export * from './cart'; export * from './product'; export * from './settings';

这样业务页面只从stores/index.ts引入自己需要的原子，依赖路径清晰，不会出现状态定义散落各处的情况。

5.2 atomWithStorage在鸿蒙侧的自定义存储适配

Jotai自带的atomWithStorage默认使用本地存储接口。在Web端是localStorage，在RN端会尝试适配AsyncStorage。鸿蒙侧的RN运行时对AsyncStorage的兼容性取决于原生模块是否配套，如果项目里没有安装对应的原生存储模块，默认的存储适配会失效，状态刷新后丢失。

我们的做法是自定义一个存储适配器，底层对接鸿蒙的持久化能力：

// stores/storage.ts import { createJSONStorage } from 'jotai/utils'; interface StorageLike { getItem: (key: string) => string | null | Promise<string | null>; setItem: (key: string, value: string) => void | Promise<void>; removeItem: (key: string) => void | Promise<void>; } export function createAsyncStorage(): StorageLike { // 这里对接鸿蒙侧通过桥接透传的持久化接口 return { getItem: async (key: string) => { const value = await NativeModules.HarmonyStorage.getItem(key); return value; }, setItem: async (key: string, value: string) => { await NativeModules.HarmonyStorage.setItem(key, value); }, removeItem: async (key: string) => { await NativeModules.HarmonyStorage.removeItem(key); }, }; }

然后把它传给atomWithStorage的第三个参数：

export const authStateAtom = atomWithStorage<AuthState>( 'auth-state', initialAuthState, createAsyncStorage() );

这样登录态就能持久化到鸿蒙本地，App重启后自动恢复。

5.3 与现有Redux共存的渐进式迁移策略

如果你现有的RN鸿蒙工程已经大规模使用Redux，不建议一次性推倒重来。我们的做法是分阶段迁移：

第一阶段，新页面和新的业务模块使用Jotai。页面内部的状态用基础原子，接口数据用异步原子加loadable，跨页面共享状态用模块级原子。

第二阶段，把Redux Store里相对独立的一部分状态迁移到Jotai。优先选择“不依赖其他Redux状态”的模块，比如用户设置、本地偏好。通过在一个自定义Hook里同时读取Redux和Jotai状态，平稳过渡。

第三阶段，当Redux里的状态只剩少量跨模块依赖时，再集中处理。整个过程可以并行工作，新页面开发不受旧架构阻塞。

用Jotai管理新状态，用Redux管理老状态，两者之间通过组件桥接，这在鸿蒙上跑了一个多月没有出现兼容性问题。

5.4 团队开发约定

项目稳定之后，我们在团队里定了三条规则：

• 原子定义必须放在模块顶层或单独的状态文件里，禁止在组件render过程中创建原子；
• 涉及业务实体的状态必须使用atomFamily，以业务ID为参数拆分原子；
• 异步状态统一使用loadable包装，避免依赖Suspense特性。

这三条规则执行之后，因为状态管理引起的bug数量下降得非常明显。

6. 性能观察与工具链：高频更新、调试和包体积

最后聊几个跟运行性能相关的问题。Jotai本身很轻量，但用得不合理同样会卡顿。开发体验方面也有一些和传统Redux项目不同的地方。

6.1 高频更新场景下的原子粒度控制和selectAtom

我们的应用里有一个实时库存监控页面，每秒从推送通道接收新的库存数据。每个商品显示可售数量、价格、预约状态。最初我们把整个页面状态合并到一个大atom里，然后用useAtom订阅，结果发现每秒一次的更新导致整个页面重渲染，滑动列表时明显掉帧。

优化方式是拆细原子粒度：

import { atom } from 'jotai'; // 库存数据按SKU拆分 export const stockBySkuAtom = atomFamily((sku: string) => atom({ available: 0, price: 0, status: 'onsale', }) ); // 页面只需要订阅当前可见的若干SKU const visibleSkuListAtom = atom<string[]>([]);

每个商品组件只订阅自己的stockBySkuAtom(sku)，推送数据到达时，只有对应组件更新，其他组件完全不受影响。实测把页面帧率从卡顿恢复到了流畅。

对于订阅大原子中某一片段的需求，用selectAtom筛选：

import { selectAtom } from 'jotai/utils'; // 只订阅总价字段，价格变化时才重渲染 const totalPriceAtom = selectAtom(cartItemsAtom, (items) => items.reduce((sum, item) => sum + item.price * item.count, 0) );

selectAtom内置了值比较逻辑，下游读取到的值没变时不会触发重渲染。这和Redux的selector优化是同一个思路，但写法更贴合React的直觉。

6.2 调试工具：鸿蒙环境下的两套方案

Jotai官方推荐使用jotai-devtools，但在鸿蒙侧RN环境里，它的浏览器扩展和自定义hook支持并不完整。我们实际采用的调试方式是：

第一，业务日志埋点。在关键派生原子和异步原子内部打印状态流转信息，观察依赖图是否正确。

第二，兼容Redux DevTools。Jotai提供了传统的debug模式，可以暴露内部状态到统一的调试面板。如果项目里已经接了Redux DevTools，这套兼容方案可以复用现有调试面板，不用额外引入新工具。

真机调试时，最常用的是在入口文件做全局状态快照：

import { useAtomValue } from 'jotai'; import { authStateAtom } from './stores/auth'; function DebugPanel() { const authState = useAtomValue(authStateAtom); return null; // 开发模式下打日志用 }

这种方式简单直接，不依赖额外工具，出错时一眼能看出当前所有关键状态。

6.3 包体积增量与启动耗时

引入Jotai后，我们特意测了一下包体积变化。整个Jotai库的生产包体积很小，压缩后约几KB量级，相比Redux加相关中间件节约了十几KB甚至更多。加上我们移除了部分MobX装饰器代码后，包体积下降更明显。

启动耗时方面，Jotai没有初始化Store的额外步骤，原子是按需创建的，因此几乎不影响启动速度。这在鸿蒙设备上特别重要，阿童木这类低配置设备上，任何多余JS执行时间都会被用户感知。

6.4 是否需要担心“太灵活”带来的约束不足

Jotai的自由度确实比Redux高，团队里刚上手的人可能会问：“没有强制规范，代码会不会写乱？”我的看法是，规范应该由团队制定，而不是由框架强制。Redux的强约束换来的往往是样板代码成本。Jotai把状态管理回归到“普通变量 + 订阅”的本质，配合合理的目录约定和代码评审，完全能控制住复杂度。

最终我个人的体会是：在鸿蒙RN适配这个特殊场景下，状态管理库的选择标准不是“功能多强大”，而是“依赖多简单”。Jotai恰好把复杂度降到了最低。现在团队的新需求默认都用Jotai写，老模块里的Redux也在逐步替换。如果你的项目正在做鸿蒙适配，或者打算新起一个RN鸿蒙工程，我会建议直接试试Jotai。它的学习成本很低，跑通一个demo只需要十分钟。真到了鸿蒙真机上踩过异步状态的坑、理顺了atomFamily的使用方式之后，你会觉得整套方案确实省心。