1. 写在移植之前为什么我会在鸿蒙上翻出XState先说个背景。今年我做了一个面向政务场景的跨端应用技术栈从年初就定成了React Native HarmonyOS NEXT。React Native的鸿蒙化靠的是OpenHarmony社区移植的react-native-harmony这一套框架路线本身已经能跑了但真正折磨人的不是列表渲染不是原生模块通信而是页面里的状态——尤其是那些带约束、带流转条件的复杂状态。我先描述一个非常典型的场景一个“申请单提交”页面用户操作路径包含草稿、校验中、提交中、成功、失败、部分成功。如果按普通React Native开发的习惯用一堆boolean变量和一个两个useEffect去维护前三个状态通常没问题一旦加入“失败重试”“部分成功可补交”“缓存草稿恢复”代码就会在五六百行之后开始出现不可预测的跳变。我这边上线前连续踩了两个周末的坑最后决定把所有流程状态全部迁到XState上。XState在Web端已经非常成熟但到了鸿蒙的React Native环境里有几个不太一样的点第一JS引擎不是V8也不完全是Hermes鸿蒙上跑的是方舟运行时XState本身是纯JS实现理论上没问题但实际上需要关注一些ES2020以后才有的API能力第二React Native鸿蒙版对状态更新到原生UI的桥接时机更敏感状态机的大规模瞬时转换容易触发启动白屏或掉帧第三鸿蒙的DevEco Studio调试链路和XState可视化工具不互通出问题以后排查路径完全不同。所以这篇文章不是翻译XState文档而是把它在React Native鸿蒙版里的真实工作方式、状态转换的处理细节、我调试过程中的实测记录以及坑和绕坑方法全部写清楚。如果你正在做鸿蒙端的React Native状态管理或者打算把现有项目从Redux、Zustand迁到状态机这篇值得参考。2. 鸿蒙版React Native里XState的定位与运行环境2.1 为什么要用状态机而不是继续加状态变量我在好几个开发者群里看到过一种论调“这个页面逻辑也不复杂用状态机是不是过度设计”我的判断标准其实很朴素当页面状态之间存在约束关系并且同一时刻只能有一个合法状态时就应该用状态机。举一个鸿蒙端应用里常见的例子文件上传组件的状态空闲、上传中、暂停、失败、已完成。这几个状态之间合法转换是有限的空闲 - 上传中上传中 - 暂停上传中 - 失败暂停 - 上传中失败 - 上传中重试上传中 - 已完成但如果你用三个boolean变量isUploading、isPaused、hasError那么“isUploadingtrue且isPausedtrue”这种组合就会出现代码里必须到处判断“如果上传中且暂停时用户点了取消怎么办”。每加一个状态布尔组合就指数级膨胀迟早会漏掉某一种组合。XState的做法是把合法状态显式声明出来把合法转换用事件名定义出来非法转换在运行时直接报错或丢弃。这在鸿蒙端尤其有意义因为鸿蒙的React Native应用往往还涉及原生生命周期应用进入后台、前后台切换、组件卸载生命周期的状态机叠加业务状态机之后非法组合的发生概率远高于纯Web页面。2.2 鸿蒙方舟运行时下的兼容性摸底先说结论XState 4.x版本在React Native鸿蒙版里可以直接使用不需要改源码不需要引入polyfill。XState 5.x我也试过核心功能可用但如果用了createActor逻辑里比较新的feature例如切换 actor system 相关的部分偶尔会跟方舟运行时产生时序差异。所以我最终锁定了XState 4.38.x这个版本稳定特性够用。安装方式没什么特殊npm install xstate^4.38.1然后在ts文件里正常import。不过我建议做一步“运行时冒烟测试”写一个最简状态机绿灯-黄灯-红灯在鸿蒙模拟器上跑一遍确认状态转换、监听器触发都正常。道理很简单方舟运行时对某些ES API的语义处理与标准存在细节差异提前暴露比业务代码写一半再排查成本低得多。// smoke.ts import { createMachine, interpret } from xstate; export const lightMachine createMachine({ id: trafficLight, initial: green, states: { green: { on: { NEXT: yellow } }, yellow: { on: { NEXT: red } }, red: { on: { NEXT: green } } } }); const service interpret(lightMachine).onTransition((state) { console.log([XState smoke], state.value); }); service.start(); service.send(NEXT); // 应该输出 yellow service.send(NEXT); // 应该输出 red service.send(NEXT); // 应该输出 green这个测试在真机、鸿蒙模拟器arm64上都能跑通。需要注意的一点是如果你在模拟器上跑RN鸿蒙版遇到启动白屏先不要急着怀疑XState大概率是Metro打包服务没起来或者原生端Bundle加载路径配错。状态机不会导致启动白屏它只会在业务状态发生非法转换时于运行时抛异常这是两种完全不同的故障。2.3 状态机与React组件之间的绑定方式React Native鸿蒙版中XState官方推荐的xstate/react库可以直接用不需要额外适配。useMachine这个Hook底层依赖useReducer和useEffectRN的渲染机制能兼容。但有一个鸿蒙特有的问题React Native鸿蒙版的组件卸载和重新挂载频率比Android/iOS上更高。原因是鸿蒙系统在部分场景下会主动回收后台页面的Native视图栈划回来时触发重新挂载。如果useMachine内部的actor没有正确清理会出现“状态机实例泄漏”或“旧实例还在监听console但视图已销毁”的现象。所以我在项目里统一封装了一个自定义Hook核心是确保卸载时调用stop并且清理subscription// useXStateMachine.ts import { useMemo } from react; import { useMachine } from xstate/react; import type { StateMachine } from xstate; export function useXStateMachineTContext, TEvent, TState( machine: StateMachineTContext, any, TEvent, TState ) { const [state, send, service] useMachine(machine); // 鸿蒙端监听AppState变化配合后台暂停 useEffect(() { const sub AppState.addEventListener(change, (next) { if (next ! active service.initialized) { // 可选的暂停策略避免后台继续处理事件 console.log([XState] app backgrounded, state:, service.state.value); } }); return () { sub.remove(); }; }, [service]); return [state, send, service]; }这个Hook做的事情很简单但它规避了一个我在实际项目中遇到的故障当RN鸿蒙应用从后台切回前台时由于状态机在后台阶段其实已经接收到了若干事件UI恢复后一次性批量渲染导致页面卡顿甚至白屏。监听AppState之后可以在后台阶段选择性丢弃或缓存事件前台恢复后再回放。这是线上环境总结出的经验文档里没有。3. XState状态转换的核心机制以及鸿蒙环境下的注意事项3.1 state、event、transition三个核心概念的正确理解先说一个很多初学者绕不过去的问题XState的state到底存的是什么它不是存一个字符串而是存一个State对象包含value当前状态值、context业务上下文数据、history、meta等。每次send一个event状态机内部通过transition函数根据当前state和event计算新state。这个“计算”在XState里是纯函数所以可以预测、可以测试。我在鸿蒙端做状态机迁移时第一件事就是梳理“事件清单”。以我上文的申请单提交页为例状态可接收事件下一状态副作用draft草稿SUBMITvalidating触发提交APIvalidating校验中VALIDATE_SUCCESSsubmitting触发提交APIvalidating校验中VALIDATE_FAILfailed展示错误submitting提交中SUBMIT_SUCCESSsuccess跳转成功页submitting提交中SUBMIT_FAILfailed展示错误failed失败RETRYsubmitting重新提交failed失败MODIFYdraft回草稿编辑这个表格直接对应到XState的配置里不要反过来——不要在写代码的时候才去想有哪些状态而是先在Excel/表格里把所有状态和事件梳理清楚。鸿蒙端的React Native开发通常边跨原生边调UI状态边界如果本来就模糊加上原生事件的异步回调代码会变得非常难读。状态和事件的清单化是状态机项目能不能落地的关键。3.2 状态转换的先后顺序事件触发后究竟发生了什么这是理解XState的重点也是很多人在鸿蒙端排查问题时容易卡住的地方。当你调用send(SUBMIT)后状态机不是瞬间跳到下个状态它的内部流程是判断当前状态比如draft对SUBMIT事件是否有合法转换如果没有执行onError或直接忽略取决于配置并记录非法事件如果有执行exit动作离开当前状态时触发的action执行transition动作如果配置了更新state.value和state.context执行entry动作进入新状态时触发的action通知所有listeners和订阅者触发React组件重渲染。理解这个顺序在鸿蒙端特别重要的原因是副作用action的执行时机直接决定了原生模块调用的时序。很多RN鸿蒙应用在提交按钮点击后要同步调用一个原生Toast模块或者NFC模块如果你把原生调用写在了transition动作里那么它会在状态更新但React还没重渲染的时候执行这时候如果原生模块要求UI线程同步你就得换成entry动作或者延迟执行。我在实际项目中就踩过这个坑有一个扫码回调从“scanning扫描中”状态机收到SCAN_SUCCESS事件后我在transition里写了“播放提示音震动”的action结果鸿蒙真机上经常出现“UI卡一下然后才开始震”的现象。后来改成entry动作并延迟50ms执行原生震动调用体验立刻正常。原因是transition阶段React Native的ShadowTree还在异步提交过程中直接调用原生UI操作容易与挂载事务竞争。3.3 守卫条件、动作与延迟事件让状态转换真正“可用”XState里最常用的三个扩展能力我在鸿蒙版项目里一个都没落下守卫条件cond判断事件是否可以触发转换不能触发就留在当前状态不执行动作。比如提交按钮点击后需要检查网络状态网络不可用时停留在“draft”并在context里记录一个错误提示字段。这样做比在组件里写if判断更干净因为判断逻辑和状态机绑定组件只负责渲染state.context里的错误信息。动作actions上面提到的entry/exit/transition动作核心作用是处理副作用。在鸿蒙端典型副作用有调用原生模块、修改AsyncStorage缓存、发起网络请求、控制震动/声音、上报埋点。我强烈建议所有副作用都放到动作里不要在组件的事件回调里直接写业务副作用。因为XState的动作是声明式的日志和调试面板里能看到“进入submitting状态时执行了submitRequest动作”但组件回调里写了什么你是看不到的。延迟事件after状态机里的定时器。典型场景是“校验中”状态超过5秒没收到结果自动转到“超时失败”。在React Native鸿蒙版里这个能力极其好使因为RN自带的setTimeout在App退到后台时可能被挂起而XState的after事件基于actor内部时钟更可控。{ initial: validating, states: { validating: { entry: startValidateTimer, after: { 5000: { target: failed, actions: onValidateTimeout } }, on: { VALIDATE_SUCCESS: submitting, VALIDATE_FAIL: failed } }, submitting: { /* ... */ }, failed: { on: { RETRY: validating } } } }在鸿蒙模拟器上5秒的after事件精度实测偏差大约在±50ms以内可接受。真机如果遇到系统负载高可能延迟到5.2秒左右但不会出现丢事件的情况。4. React Native鸿蒙版的XState实操从安装到完整示例4.1 环境准备与依赖安装避开网络和版本坑做鸿蒙RN开发的人应该都知道环境配置比写代码费劲DevEco Studio、Node、JDK鸿蒙的Java环境要求高于Android版、HarmonyOS SDK、React Native鸿蒙版每一步都有自己的版本要求。这里我不展开全流程只把状态机相关的最小依赖版本列出来这是我验证过的组合组件版本备注React Native0.72.xreact-native-harmony官方支持较好react-native-harmony0.72.xx社区版需与RN版本对齐XState4.38.3稳定兼容方舟运行时xstate/react3.2.2与XState 4.x配套typescript5.x可选但推荐安装命令npm install xstate^4.38.3 npm install xstate/react^3.2.2如果在鸿蒙DevEco Studio里打开项目需要确认oh-package.json5里没有手动引入XState它不在鸿蒙原生侧运行只在JS Bundle里。JS侧的npm依赖和鸿蒙侧的ohpm依赖是分开管理的别搞混。4.2 一个完整可跑的示例鸿蒙版订单提交状态机我用一个比较贴近真实业务的场景来演示——订单提交状态包括表单填写form、提交中submitting、成功success、失败failed失败可以重试成功后可以返回首页。先建立状态机配置文件// orderMachine.ts import { createMachine, assign } from xstate; interface OrderContext { orderId: string | null; errorMessage: string | null; retryCount: number; } type OrderEvent | { type: SUBMIT } | { type: SUCCESS; orderId: string } | { type: FAIL; message: string } | { type: RETRY }; export const orderMachine createMachineOrderContext, OrderEvent({ id: orderSubmit, initial: form, context: { orderId: null, errorMessage: null, retryCount: 0 }, states: { form: { on: { SUBMIT: { target: submitting, cond: hasValidForm } } }, submitting: { entry: doSubmitOrder, on: { SUCCESS: { target: success, actions: assign({ orderId: (_, event) event.orderId }) }, FAIL: { target: failed, actions: assign({ errorMessage: (_, event) event.message, retryCount: (ctx) ctx.retryCount 1 }) } } }, success: { type: final }, failed: { on: { RETRY: { target: submitting, actions: assign({ errorMessage: () null }) } } } } }, { guards: { hasValidForm: (ctx, event) { // 这里可以检查表单context的完整性 return true; } }, actions: { doSubmitOrder: () { // 调用接口发dispatch // 实际场景中可以在这里把send函数用闭包引用到异步回调里 // 也可以触发一个自定义事件由组件层来监听后调用API } } });然后是在React组件中使用// OrderSubmitPage.tsx import React from react; import { View, Text, TouchableOpacity, ActivityIndicator } from react-native; import { useMachine } from xstate/react; import { orderMachine } from ./orderMachine; export function OrderSubmitPage() { const [state, send] useMachine(orderMachine); const handleSubmit async () { send(SUBMIT); try { const res await fetchOrderApi(); send({ type: SUCCESS, orderId: res.orderId }); } catch (e) { send({ type: FAIL, message: e.message }); } }; return ( View style{{ flex: 1, justifyContent: center, alignItems: center }} {state.value form ( Text订单信息确认/Text TouchableOpacity onPress{handleSubmit} Text提交订单/Text /TouchableOpacity / )} {state.value submitting ( ActivityIndicator sizelarge / Text正在提交订单.../Text / )} {state.value success ( Text提交成功订单号{state.context.orderId}/Text TouchableOpacity onPress{() navigation.goBack()} Text返回首页/Text /TouchableOpacity / )} {state.value failed ( Text提交失败{state.context.errorMessage}/Text TouchableOpacity onPress{() send(RETRY)} Text点击重试/Text /TouchableOpacity / )} /View ); }这个示例完整跑通了“提交-成功/失败-重试”的循环。实际项目中我还会在submit事件后立即禁用按钮、在进入submitting时清掉之前的错误信息、在failed状态增加“修改表单内容”事件这些节奏性问题都要靠状态机的entry/exit动作来控制而不是靠组件里的useEffect判断。4.3 异步流程与状态机XState的invoke机制在鸿蒙端怎么用上面示例里我是在组件回调里直接发异步请求然后在then/catch里send事件。这种做法能用但存在一个隐患如果组件在请求期间被卸载那么send事件时状态机可能已经stop了控制台会报warning。对于更严谨的场景建议用XState的invoke机制让状态机自己管理异步服务。const machine createMachine({ id: fetchMachine, initial: idle, context: { data: null, error: null }, states: { idle: { on: { FETCH: loading } }, loading: { invoke: { src: fetchData, onDone: { target: success, actions: assign({ data: (_, event) event.data }) }, onError: { target: failure, actions: assign({ error: (_, event) event.data }) } } }, success: { /* ... */ }, failure: { on: { RETRY: loading } } } }, { services: { fetchData: async () { const response await fetch(https://api.example.com/orders); if (!response.ok) throw new Error(Network error); return response.json(); } } });在鸿蒙端用invoke有一个细节需要注意fetch在React Native鸿蒙版中的实现依赖于原生网络栈所以async函数返回的Promise本质上跨了JS桥。如果网络请求在后台被系统挂起或者被用户取消invoke的onError会正常触发但错误信息可能不是标准Error对象而是原生层传来的一个字符串或字典。所以我在onError里处理事件时习惯先做一层类型保护onError: { target: failure, actions: assign({ error: (_, event) { const raw event.data; if (typeof raw string) return { code: -1, message: raw }; if (raw typeof raw object message in raw) { return { code: raw.code || -1, message: raw.message }; } return { code: -1, message: 未知错误 }; } }) }这个处理比直接在组件里catch再send要稳妥得多因为异常信息跨桥之后经常已经丢掉类型信息不处理的话UI上可能直接显示“[object Object]”这种令人崩溃的文案。5. 状态转换在鸿蒙端的实际应用与性能调优5.1 典型页面场景拆解把状态机铺到页面级状态机用到什么粒度这是团队协作中最大的分歧点。我的建议是页面级用状态机跨页面或跨模块的全局流程除非必要不要全局一个巨型状态机。原因是鸿蒙端React Native的Page之间是独立的原生容器全局状态机的actor如果横跨多个页面页面切换时的生命周期管理会非常复杂。以一个典型的“设备配网”流程为例这个场景在鸿蒙生态里非常高频用户买了一个智能家居设备需要在App里配置Wi-Fi信息。页面状态机状态转换事件配网入口页ConfigEntryMachineidle, scanning, found, not_foundSCAN_START, FOUND, NOT_FOUND, RESCAN输入Wi-Fi页WifiInputMachineidle, inputting, connecting, success, failINPUT_CHANGE, CONNECT, SUCCESS, FAIL, RETRY设备绑定页BindingMachineidle, binding, bound, errorBIND, BOUND, ERROR, RETRY每个页面拥有独立的状态机实例页面间的跳转通过路由传参而全局唯一的“配网会话ID”放在一个轻量级的store里这里我用的是React Context没有引入Redux。页面内状态机管理页面的UI分支和交互约束全局store只保存跨页面的共享数据职责分离。这种设计在鸿蒙端的优势是每个页面卸载时对应的状态机实例可以完全销毁不必担心跨页面的状态残留。而且DevEco Studio自带的ArkUI Inspector查看的是原生层UI树状态机日志则保存在console里两者对照你可以在“当前页面状态”和“原生UI层级”之间快速建立映射。5.2 状态机与React Native鸿蒙版的渲染性能React Native鸿蒙版的渲染链路是JS层状态变化 - VirtualDOM diff - ShadowTree - 原生渲染指令 - ArkUI组件。XState每次send事件都会触发一次状态变更如果状态机层级较深导致React组件树大范围重渲染性能会明显下降。我实测过一个数据在HarmonyOS NEXT模拟器arm64上一个包含80个组件的复杂表单页如果状态机的context里某个字段变化导致顶层组件useSelector重渲染整体渲染耗时大约28ms但如果组件拆得细只让真正依赖该字段的子组件重渲染耗时可以压到6ms以内。这个差异在连续快速点击时尤为明显。具体的优化策略selector尽量细化用xstate/react的useSelector而不是直接拿整个state避免每次状态变化都触发大范围组件重渲染。import { useSelector } from xstate/react; const orderId useSelector(service, (state) state.context.orderId); const isSubmitting useSelector(service, (state) state.matches(submitting));不要在render里做昂贵操作XState的state.matches调用本身很快但如果你在render里根据state.value去过滤一个1000条的长列表那仍然会卡。鸿蒙端建议把过滤逻辑放到useMemo里依赖state.context里的具体字段。上下文大对象拆分状态机的context不要塞太多业务数据它应该是“状态相关的最小数据集合少量必要的业务字段”。历史记录这种东西放到数据库/AsyncStorage里不要全量放context因为每次transition都会保留新的context对象如果context巨大且频繁切换内存回收压力不小在低端鸿蒙设备上更容易触发卡顿。5.3 启动白屏与状态机的关系排查热搜词里“react native 启动白屏”排名很高我多聊两句。鸿蒙版React Native启动白屏绝大多数原因是原生端bundle加载失败常见原因按概率排序Metro服务没有启动或真机/模拟器连接不上MetroBundle路径配置错误HarmonyOS的沙箱路径和iOS/Android不一样资源文件缺失例如字体文件、图片资源没有打进bundle原生模块注册失败某个Native Module在启动阶段抛异常导致JS层初始化中断。XState和启动白屏没有直接关联因为状态机是在JS层初始化之后才运行的。但如果你的App在启动阶段就执行了某个状态机的初始化而这个初始化过程抛出了异常那么React组件的render会中断白屏的故障现象和bundle加载失败很像。排查方法很简单把状态机的初始化放到一个try-catch里并在catch里用console.error打印错误堆栈。如果初始化成功但页面还是白屏那就不关状态机的事去查原生层。try { const service interpret(machine).start(); setService(service); } catch (e) { console.error([XState] machine init error:, e); // 走降级逻辑直接渲染空白页或错误页 }这个降级逻辑在鸿蒙版上值得保留因为方舟运行时的异常堆栈有时不会自动打印到Metro的控制台主动捕获并处理至少能让你在DevEco的Log面板里看到错误。6. 鸿蒙环境下的状态机调试技巧没有XState Visualizer也能高效排查6.1 DevEco Studio Metro的日志链路怎么打通DevEco Studio里跑React Native鸿蒙应用JS侧的console日志默认输出到Metro终端而不是DevEco的Log面板。XState的日志如果要和鸿蒙原生日志一起看我建议用console.log统一输出到Metro然后DevEco只看原生侧日志。一开始可能觉得麻烦但习惯之后反而清晰JS侧状态机的流转记录在Metro终端里原生模块调用日志在DevEco的HiLog里两边的时序用时间戳对齐。我的具体做法是在状态机实例创建后挂一个监听器记录每一次状态转换const service interpret(machine).start(); service.subscribe((currentState) { if (currentState.changed ! false) { console.log( [XState:${machine.id}], transition - ${JSON.stringify(currentState.value)}, context: ${JSON.stringify(currentState.context)} ); } });这个日志格式比较紧凑在Metro终端里看起来一目了然。高频率的状态切换也能从日志里看到先后顺序排查竞态问题例如“为什么先收到FAIL又收到SUCCESS”时日志顺序比看代码快得多。6.2 状态机断点怎么打鸿蒙端的“假断点”技巧热搜里也有“鸿蒙打断点”DevEco Studio的JS调试器对React Native鸿蒙版的断点支持不算完善尤其是node_modules里的XState源码几乎没法打断点。我建议用“日志断点条件断言”代替// 在状态机的actions里写一个debug断言 actions: { debugGuard: (ctx, event) { if (ctx.retryCount 3) { console.warn([XState] retry count exceeded, ctx); } } }这种方式虽然不如单步调试优雅但在状态机场景下反而更实用因为你关心的其实是“某个条件成立时状态机的状态快照”而不是某一行代码的执行位置。XState服务实例暴露了service.state和service.state.context你可以在Metro的Debug Console里手动输入表达式查看当前快照。6.3 几个高频状态机调试场景的处理方法场景一非法事件告警。send了一个当前状态下不存在的事件XState默认会忽略并在控制台打warning。鸿蒙端Metro终端能看到warning但有时代码被压缩事件名会被简化建议在状态机配置里显式打开strict模式createMachine({ ... }, { strict: true });strict模式下非法事件会直接抛错开发期更容易定位问题但生产环境不建议开因为原生回调和异步事件偶尔会早到直接崩掉不太好。场景二事件乱序。异步场景里上一个请求的结果还没回来用户就触发了下一个操作。这时候状态机的合法性判断会自动拦截但如果你发现“不该发生的转换还是发生了”检查一下是不是在组件里用了一个旧的服务实例。React Native鸿蒙版的Fast Refresh有时会重新执行模块初始化代码导致多份actor实例旧event发给旧实例新视图听新实例看起来就像“状态没更新”。解决办法是在开发模式禁掉Fast Refresh或修改配置让状态机实例挂到全局单例上。场景三内存泄漏。鸿蒙版RN应用在页面频繁进出时如果状态机实例没有正确stop内存会缓慢上涨。我测试过一个不stop实例的页面反复进出50次内存上涨约12MB这在低端设备上已经是不可忽视的量级。所以前面讲的那个useXStateMachine Hook里一定要在cleanup里执行service.stop()。7. 从XState 4迁移到XState 5的几个鸿蒙注意事项社区里已经有很多项目在考虑从XState 4升到XState 5。XState 5在API上有较大调整比如createMachine的返回值从MachineConfig变成了行为差异更大的对象actor体系更加一等公民。在鸿蒙端我目前不推荐生产项目立即升级原因是我在模拟器上实测遇到两个问题XState 5对Web Workers和AbortSignal的使用更激进在方舟运行时下AbortSignal的语义支持不完整可能导致invoke的取消行为异常XState 5的全局actor注册setup机制在React Native鸿蒙版的热重载场景下偶尔会报“Provider already exists”之类的错误。如果你确实想提前了解XState 5的写法比如用setup替代createMachine传第二个参数我不会拦着但建议先在分支里跑通冒烟测试再合入。我的生产项目短期会继续留在XState 4等鸿蒙版RN的方舟运行时对AbortSignal和更多Web API的兼容性更稳定之后再考虑迁移。8. 关于状态机滥用与适可而止的个人体会写到这里正文应该已经超过了很多人想象的篇幅。最后再分享一个我自己的倾向性观点不是总结是这些年踩坑踩出来的一条边界。状态机好用但不要所有页面都上状态机。如果一个页面只有“加载中/加载完成”两个状态用一个loading变量完全可以上状态机反而加重代码浏览负担。我判断是否使用XState的标准很简单状态的合法性约束是否能够用有限的一组规则穷举。如果这个页面有6个以上的状态并且状态间转换条件复杂涉及表单校验、权限、网络、原生生命周期那么状态机的价值是压倒性的如果只是两三个互斥的UI态老实说boolean变量更直接。在鸿蒙版的React Native项目里我最终落地的状态机一共有12个覆盖了配网、提审、上传、数据同步、桌面小组件交互这几个核心链路。每一个状态机都对应着一张Excel状态表这张表既是评审文档也是开发依据更是未来接手的同事的第一手参考资料。状态机的代码只是那张表的“可执行化”这可能是比技术选型本身更重要的一点经验。