状态管理选型笔记

ArkTS 的状态管理是声明式 UI 的核心命题：状态怎么组织、更新怎么驱动界面。这篇给选型笔记——按应用规模与团队习惯的决策参考。

▍先懂原理
声明式 UI 的基本循环：状态变化驱动界面刷新（状态是源，界面是像）。你要管理的是：状态的定义（什么数据是状态——会变的、要驱动界面的）、状态的归属（哪层组件拥有它）、变化的传播（谁改它、改了之后谁刷新）。

▍常用的几类方案
基础的状态装饰器（组件内部状态——小型界面自洽的状态够用）；父子传递（单向数据流——父传子 props、子回父事件，中型界面的标准解）；共享状态对象（跨组件的全局状态——多组件联动、跨页面的数据共享）；应用级的状态管理（大型应用的多模块状态协调——分层的状态架构）。

▍选型的三问
状态的范围（一个组件内？父子链？跨页面？——范围决定方案档位）；状态的复杂度（简单值？嵌套对象？集合？——复杂结构对观测与更新的设计要求不同）；团队规模（单人小项目怎么快怎么来；多人大项目要状态架构的纪律——状态的变更路径可追踪）。

▍实战的几条心得
状态最小化（不是所有数据都是状态——不驱动界面的数据用普通变量或存储层）；变更集中（状态的修改路径收敛——散落在各处直接改状态是维护灾难的开始）；派生用计算（从状态算出来的值用派生机制——别手动同步两份状态）；双层架构的特别注意（移植工程的 ArkTS 壳的状态要薄——壳的状态尽量只是 native 世界的镜像与调度，别在壳里长出第二份业务状态）。

▍反模式清单
万物皆全局（什么状态都扔全局——刷新风暴与调试地狱）；双向绑定的滥用（状态流向不清——改了不知道谁改的）；巨型状态对象（一个对象装一切——任何小变化触发大刷新）。

更多状态管理的实战案例，欢迎到 apps 板块翻看 56 篇《鸿蒙PC适配全记录》系列实录。