引子状态管理是 ArkUI 的命脉写鸿蒙应用90% 的 bug 都和状态管理有关——数据变了 UI 没更新、子组件拿不到父组件的值、对象属性改了但页面没刷新。ArkUI 提供了六种状态管理工具每种解决不同的问题。选错了代码会越来越乱选对了数据流清晰bug 自然少。今天就从实际开发场景出发拆解 State、Prop、Link、Provide/Consume、Observed/ObjectLink、Watch 六个装饰器的用法、区别和选型逻辑。完整效果先搞懂一个问题状态从哪来ArkUI 是声明式 UI——UI 是状态的函数UI f(state)。状态变了UI 自动更新。但状态存在哪里是个问题只在当前组件用→ 存组件内部父子组件共享→ 存父组件传给子组件祖孙多层传递→ 存全局跨层传递对象的某个属性变了→ 需要深度观察六种装饰器对应四种场景搞清楚场景就能选对工具。State组件内部的状态Componentstruct Counter{Statecount:number0;build(){Column(){Text(点击了${this.count}次)Button(1).onClick((){this.count;})}}}作用域State变量只在当前组件内有效。外部无法直接修改。触发更新的条件基本类型number、string、boolean值变化就触发对象/数组引用变化才触发this.obj newObj属性变化不触发常见错误// 错误修改对象属性UI 不更新Stateuser:UserInfo{name:张三,age:25};this.user.age26;// UI 不刷新// 正确替换整个对象this.user{...this.user,age:26};// UI 刷新适用场景组件内部的私有状态——计数器、开关、输入框的值、当前选中的 Tab。Prop父传子的单向绑定// 父组件Componentstruct Parent{Statemessage:stringhello;build(){Column(){Child({msg:this.message})Button(改消息).onClick((){this.messageworld;})}}}// 子组件Componentstruct Child{Propmsg:string;build(){Text(this.msg)}}数据流Parent.message → Child.msg单向父→子父组件的message变了子组件的msg自动更新。但子组件不能反过来修改父组件的message。Prop 的拷贝语义Prop会拷贝父组件的值。子组件拿到的是副本修改副本不影响父组件。// 子组件Propmsg:string;this.msgchanged;// 只改自己父组件不受影响适用场景父组件传配置给子组件——标题文字、是否显示、颜色值。子组件只负责展示不负责修改。Link父子双向绑定// 父组件Componentstruct Parent{Statecount:number0;build(){Column(){Child({count:$count})// 用 $ 传引用Text(父组件:${this.count})}}}// 子组件Componentstruct Child{Linkcount:number;build(){Button(子组件 1).onClick((){this.count;})}}数据流Parent.count ↔ Child.count双向父↔子子组件修改count父组件的count也会变。两边同步。$ 符号的含义Child({count:$count})// 传引用Child({count:this.count})// 传值错误$count传的是变量的引用this.count传的是值。用错了双向绑定就失效。Link vs Prop特性PropLink数据流父→子单向父↔子双向子组件修改不影响父组件同步到父组件传值方式msg: this.valuecount: $value适用场景子组件需要修改父组件的状态——表单输入、开关切换、列表项的选中状态。Provide/Consume跨层传递// 祖先组件Componentstruct Grandparent{Provide(theme)currentTheme:stringdark;build(){Column(){Parent()Button(切换主题).onClick((){this.currentThemethis.currentThemedark?light:dark;})}}}// 中间组件不需要传递 themeComponentstruct Parent{build(){Child()}}// 后代组件Componentstruct Child{Consume(theme)currentTheme:string;build(){Text(当前主题:${this.currentTheme})}}数据流Grandparent.currentTheme → Child.currentTheme跨层祖先→后代中间的 Parent 组件不需要知道theme的存在数据直接穿透传递。为什么需要 keyProvide(theme)currentTheme:string;Consume(theme)currentTheme:string;theme是 keyProvide和Consume必须用同一个 key 才能匹配。一个组件可以 Provide 多个值用不同的 key 区分。适用场景全局配置——主题、语言、用户信息、登录状态。不需要层层传递直接跨层获取。Observed/ObjectLink对象深度观察ObservedclassUserInfo{name:string;age:number0;}// 父组件Componentstruct Parent{Stateuser:UserInfonewUserInfo();build(){Column(){Child({user:this.user})Button(改年龄).onClick((){this.user.age;})}}}// 子组件Componentstruct Child{ObjectLinkuser:UserInfo;build(){Text(${this.user.name}${this.user.age})}}Observed 的作用给类加Observed框架会深度观察这个类的实例。当实例的属性变化时引用这个实例的组件会更新。ObjectLink 的作用子组件用ObjectLink接收Observed对象就能观察到属性的变化。State Observed 的组合// 父组件用 State Observed 类Stateuser:UserInfonewUserInfo();// 子组件用 ObjectLinkObjectLinkuser:UserInfo;父组件修改this.user.age子组件会更新。不需要替换整个对象。为什么 State 单独不行State只观察引用变化不观察属性变化。如果UserInfo没加Observedthis.user.age不会触发子组件更新。Observed ObjectLink vs State场景用 State用 Observed ObjectLink基本类型✅不需要对象替换✅不需要对象属性修改❌✅父子共享对象❌✅适用场景列表项的内部状态——每个列表项是一个对象修改某个项的属性比如收藏、展开其他项不受影响。Watch监听状态变化Componentstruct SearchBox{StateWatch(onKeywordChange)keyword:string;onKeywordChange():void{console.log(关键词变了:${this.keyword});// 触发搜索请求}build(){TextInput({text:this.keyword}).onChange((v:string){this.keywordv;})}}Watch 的触发时机状态值变化时自动调用Watch指定的函数。在函数里可以做副作用——发请求、打日志、更新其他状态。为什么不在 onChange 里直接处理// 方案一在 onChange 里处理.onChange((v:string){this.keywordv;this.doSearch(v);// 需要手动调用})// 方案二用 WatchStateWatch(onKeywordChange)keyword:string;// 只要 keyword 变了自动触发不管从哪里改的Watch的好处是不管状态从哪里被修改都会触发。如果以后有其他地方修改keyword比如清空按钮不需要重复写处理逻辑。适用场景搜索防抖、表单校验、日志记录、状态同步。选型决策树需要管理状态 ├─ 只在组件内部用 → State ├─ 父子组件共享 │ ├─ 子组件只读 → Prop │ └─ 子组件要改 → Link ├─ 跨多层传递 → Provide/Consume ├─ 对象属性要深度观察 → Observed ObjectLink └─ 状态变化要触发副作用 → Watch六种装饰器的对比表装饰器作用域数据流修改权适用场景State组件内组件内组件内私有状态Prop父→子单向子可改不影响父配置传递Link父↔子双向双方都可改表单输入Provide祖先→后代跨层祖先改后代读全局配置Consume后代读祖先跨层后代读祖先改全局配置Observed对象属性深度观察任何持有引用的组件列表项状态ObjectLink子组件读对象深度观察子组件可改列表项状态Watch任意监听变化触发回调副作用处理踩坑记录坑 1Link 传值用了 this 而不是 $// 错误Child({count:this.count});// 正确Child({count:$count});坑 2Observed 漏加// 错误UserInfo 没加 ObservedclassUserInfo{name:string;}// 正确ObservedclassUserInfo{name:string;}坑 3Provide 和 Consume 的 key 不一致// 祖先Provide(theme)currentTheme:string;// 后代Consume(color)currentTheme:string;// key 是 color匹配不上坑 4Prop 没有默认值// 错误Prop 没有默认值编译报错Propmsg:string;// 正确给默认值Propmsg:string;坑 5Watch 的函数名拼错StateWatch(onChage)keyword:string;// 函数名拼错不会报错但不会触发坑 6State 数组的更新// 错误push 不触发更新this.items.push(newItem);// 正确用展开运算符this.items[...this.items,newItem];代码改进建议1. 状态下沉把状态放在需要它的最小组件里。如果只有子组件用不要放父组件。2. 避免过度使用 ProvideProvide是全局状态用多了会让数据流难以追踪。优先用 Prop/Link 传参。3. 用 Watch 替代多处 onChange如果一个状态变化需要在多个地方响应用 Watch 集中处理比分散在各处的 onChange 更好维护。4. Observed 对象的不可变更新虽然 Observed 支持属性修改但用不可变更新替换对象更安全不容易出 bug。5. 状态管理的测试每个 State 变量都应该有对应的测试用例验证状态变化是否触发预期的 UI 更新。总结ArkUI 的六种状态管理工具解决四种场景组件内部State、父子传递Prop/Link、跨层传递Provide/Consume、对象深度观察Observed/ObjectLink。Watch 是通用的副作用触发器可以搭配任何装饰器使用。适用边界这个部分适合用作 ArkUI 状态管理的系统性学习涵盖了六个装饰器的用法、区别、选型、踩坑和最佳实践。但如果要深入某个具体装饰器比如 Observed 的实现原理、Provide 的依赖注入机制还需要更底层的分析。说白了状态管理就是把数据放在对的地方。放在对的地方UI 自动更新放在错的地方bug 满天飞。