先把相关概念说清楚知识点在这个问题里怎么看自定义组件冻结功能用来写多页面栈、TabContent、LazyForEach 和 BuilderNode 混用时的刷新边界状态管理 V1 向 V2 迁移用来拆 State 到 Local、Param、Once、Event 的迁移判断Provider / Consumer用来解释跨层级双向同步不再把参数一路传到底BuilderNode / 自定义声明式节点用来解释动态节点、预览节点、弹窗节点和普通 Builder 的边界Computed 计算属性用来解释重复计算、列表统计和派生状态的缓存边界资料入口https://developer.huawei.com/consumer/cn/doc/harmonyos-guides/arkts-custom-components-freezehttps://developer.huawei.com/consumer/cn/doc/harmonyos-guides/arkts-v1-v2-migration-inner-componenthttps://developer.huawei.com/consumer/cn/doc/harmonyos-guides/arkts-new-provider-and-consumerhttps://developer.huawei.com/consumer/cn/doc/HarmonyOS-Guides/arkts-user-defined-arktsnode-buildernodehttps://developer.huawei.com/consumer/cn/doc/harmonyos-guides/arkts-new-computed这类问题不要先背 API 名称先看状态从哪里来、经过哪些组件、最后由谁改掉。下面用两个小例子把链路拆开重点看问题怎么复现、怎么改以及改完以后怎么验证。组件层级深了以后最常见的难受点是参数一路往下传。首页有关键词、分类、排序外层传给列表列表传给空态空态再传给按钮按钮点击又要回到最外层。代码能写但后面很难看清谁真正负责这个状态。Provider和Consumer可以减少这种中间层转发不过它也不是随便替代所有参数的全局仓库。我会先定一条规则只有多个层级都需要读写、而中间层只是转交的状态才考虑 Provider/Consumer。普通父子参数继续用 Param 和 Event。这样不会把所有状态都塞进一个跨层共享桶里。什么适合共享什么不适合状态是否适合 Provider/Consumer理由当前筛选条件适合列表、空态、工具条都要读操作区要改页面主题/密度适合多层 UI 都要读变化频率低单个卡片展开态不适合卡片自己或列表持有即可表单临时输入不适合还没提交前不应该影响全局请求 loading看场景如果只影响局部不要跨层共享这个表可以避免一个误区为了省参数把所有字段都 Provider 出去。那样短期少写几行长期会失去状态归属。案例一筛选条件一路传到底怎么改先看旧写法。中间组件本来不关心筛选只是为了把参数传给更深层组件不得不接一堆字段。ComponentV2struct RecipePage{Localkeyword:stringLocalcategory:stringallbuild(){Column(){RecipeToolbar({keyword:this.keyword,category:this.category})RecipeListSection({keyword:this.keyword,category:this.category})}}}如果RecipeListSection下面还有空态、推荐按钮、结果统计参数会越传越远。更稳的方式是把筛选条件作为跨层共享状态放在页面根部。ObservedV2classRecipeFilterState{Tracekeyword:stringTracecategory:stringallreset():void{this.keywordthis.categoryall}}ComponentV2struct RecipePage{Provider(filterState)filterState:RecipeFilterStatenewRecipeFilterState()build(){Column(){RecipeToolbar()RecipeListSection()}}}深层组件只消费自己需要的状态ComponentV2struct EmptyActionBar{Consumer(filterState)filterState:RecipeFilterStatenewRecipeFilterState()build(){Row({space:8}){Text(当前关键词${this.filterState.keyword||未输入})Button(清空条件).onClick(()this.filterState.reset())}}}这样写以后中间层不用再做参数搬运读写链路也很明确页面提供筛选状态深层组件消费筛选状态。案例二底部统计也能共享但不要把它写成大杂烩购物清单一类页面常有底部统计已选数量、总数量、估算价格。这个状态列表、底部栏、弹窗都可能要读。如果每层都传代码会很长。可以共享一个统计模型但模型要小。ObservedV2classCheckoutSummaryState{TracecheckedCount:number0TracetotalCount:number0update(checked:number,total:number):void{this.checkedCountcheckedthis.totalCounttotal}getlabel():string{return已选${this.checkedCount}项 / 共${this.totalCount}项}}我不会把列表数据、筛选条件、弹窗状态、请求状态都放进这个类。它只负责统计。这样底部栏消费它时刷新范围可控也不容易出现“改筛选条件把底部统计也带乱”的问题。ComponentV2struct CheckoutFooter{Consumer(summaryState)summaryState:CheckoutSummaryStatenewCheckoutSummaryState()build(){Row(){Text(this.summaryState.label)Blank()Button(生成清单).enabled(this.summaryState.checkedCount0)}}}两种方案怎么选方案好处风险Param Event链路直观适合父子组件层级深时参数搬运多Provider Consumer减少中间层转发容易被滥用成全局状态独立 Store/Repository适合业务数据UI 状态过度下沉会变复杂我的选择是父子之间优先 Param/Event跨三层以上、多个组件都要读写的 UI 状态再用 Provider/Consumer持久化业务数据不要直接塞进去还是走 Repository。本地怎么验证Demo 里我验证两个结果。第一深层空态按钮清空筛选后顶部工具条和列表条件同时变化第二底部统计更新时不影响筛选状态。classProviderConsumerProbe{filter:RecipeFilterStatenewRecipeFilterState()summary:CheckoutSummaryStatenewCheckoutSummaryState()clearFromDeepChild():void{this.filter.reset()}checkTwoStoresSeparated():boolean{this.summary.update(2,5)returnthis.filter.keywordthis.summary.checkedCount2}}验证通过以后我才会把这种共享方式写进页面规范。它解决的是跨层参数搬运不是所有状态管理问题。以后怎么避免使用 Provider/Consumer 前先写一句话这个状态为什么必须跨层共享如果答案只是“少传几个参数”先不要用。只有中间层完全不关心、深层组件确实需要读写、状态模型又能保持很小才适合上这个能力。我会留下的排查清单这类问题以后不要只靠肉眼看页面是否正常。第一步先把状态来源写清楚它来自页面自己、父组件输入、跨层共享还是异步任务返回。第二步把触发动作写清楚用户点击、数据刷新、页面切换、组件重新激活分别会改哪些字段。第三步看刷新范围当前可见 UI 是否刷新不可见组件是否被带着刷新派生计算是否重复执行。第四步再看副作用请求、数据库写入、日志统计和缓存更新有没有被误放到 UI 派生逻辑里。我更建议把这些检查沉到项目代码评审里。以后遇到类似问题先按“复现动作、状态归属、解决方案、验证结果、如何避免”五项过一遍如果其中一项说不清楚就不要急着把新 API 写进正文或提交到项目里。这样文章能解释清楚代码也能经得起下一次改需求。还有一个实际取舍如果 Demo 写完以后发现解释全靠口头补充说明这个方案还没有封装好。能抽成一个小工具、一个组件、一个 controller 或一条项目规则才说明它不是临时补丁。文章里也应该把这个取舍讲出来让读者知道什么时候照着用什么时候应该换方案。最后再补一次边界验证改动前后都要保留最小复现步骤方便后面版本升级时重新跑一遍。
先把相关概念说清楚知识点在这个问题里怎么看自定义组件冻结功能用来写多页面栈、TabContent、LazyForEach 和 BuilderNode 混用时的刷新边界状态管理 V1 向 V2 迁移用来拆 State 到 Local、Param、Once、Event 的迁移判断Provider / Consumer用来解释跨层级双向同步不再把参数一路传到底BuilderNode / 自定义声明式节点用来解释动态节点、预览节点、弹窗节点和普通 Builder 的边界Computed 计算属性用来解释重复计算、列表统计和派生状态的缓存边界资料入口https://developer.huawei.com/consumer/cn/doc/harmonyos-guides/arkts-custom-components-freezehttps://developer.huawei.com/consumer/cn/doc/harmonyos-guides/arkts-v1-v2-migration-inner-componenthttps://developer.huawei.com/consumer/cn/doc/harmonyos-guides/arkts-new-provider-and-consumerhttps://developer.huawei.com/consumer/cn/doc/HarmonyOS-Guides/arkts-user-defined-arktsnode-buildernodehttps://developer.huawei.com/consumer/cn/doc/harmonyos-guides/arkts-new-computed这类问题不要先背 API 名称先看状态从哪里来、经过哪些组件、最后由谁改掉。下面用两个小例子把链路拆开重点看问题怎么复现、怎么改以及改完以后怎么验证。组件层级深了以后最常见的难受点是参数一路往下传。首页有关键词、分类、排序外层传给列表列表传给空态空态再传给按钮按钮点击又要回到最外层。代码能写但后面很难看清谁真正负责这个状态。Provider和Consumer可以减少这种中间层转发不过它也不是随便替代所有参数的全局仓库。我会先定一条规则只有多个层级都需要读写、而中间层只是转交的状态才考虑 Provider/Consumer。普通父子参数继续用 Param 和 Event。这样不会把所有状态都塞进一个跨层共享桶里。什么适合共享什么不适合状态是否适合 Provider/Consumer理由当前筛选条件适合列表、空态、工具条都要读操作区要改页面主题/密度适合多层 UI 都要读变化频率低单个卡片展开态不适合卡片自己或列表持有即可表单临时输入不适合还没提交前不应该影响全局请求 loading看场景如果只影响局部不要跨层共享这个表可以避免一个误区为了省参数把所有字段都 Provider 出去。那样短期少写几行长期会失去状态归属。案例一筛选条件一路传到底怎么改先看旧写法。中间组件本来不关心筛选只是为了把参数传给更深层组件不得不接一堆字段。ComponentV2struct RecipePage{Localkeyword:stringLocalcategory:stringallbuild(){Column(){RecipeToolbar({keyword:this.keyword,category:this.category})RecipeListSection({keyword:this.keyword,category:this.category})}}}如果RecipeListSection下面还有空态、推荐按钮、结果统计参数会越传越远。更稳的方式是把筛选条件作为跨层共享状态放在页面根部。ObservedV2classRecipeFilterState{Tracekeyword:stringTracecategory:stringallreset():void{this.keywordthis.categoryall}}ComponentV2struct RecipePage{Provider(filterState)filterState:RecipeFilterStatenewRecipeFilterState()build(){Column(){RecipeToolbar()RecipeListSection()}}}深层组件只消费自己需要的状态ComponentV2struct EmptyActionBar{Consumer(filterState)filterState:RecipeFilterStatenewRecipeFilterState()build(){Row({space:8}){Text(当前关键词${this.filterState.keyword||未输入})Button(清空条件).onClick(()this.filterState.reset())}}}这样写以后中间层不用再做参数搬运读写链路也很明确页面提供筛选状态深层组件消费筛选状态。案例二底部统计也能共享但不要把它写成大杂烩购物清单一类页面常有底部统计已选数量、总数量、估算价格。这个状态列表、底部栏、弹窗都可能要读。如果每层都传代码会很长。可以共享一个统计模型但模型要小。ObservedV2classCheckoutSummaryState{TracecheckedCount:number0TracetotalCount:number0update(checked:number,total:number):void{this.checkedCountcheckedthis.totalCounttotal}getlabel():string{return已选${this.checkedCount}项 / 共${this.totalCount}项}}我不会把列表数据、筛选条件、弹窗状态、请求状态都放进这个类。它只负责统计。这样底部栏消费它时刷新范围可控也不容易出现“改筛选条件把底部统计也带乱”的问题。ComponentV2struct CheckoutFooter{Consumer(summaryState)summaryState:CheckoutSummaryStatenewCheckoutSummaryState()build(){Row(){Text(this.summaryState.label)Blank()Button(生成清单).enabled(this.summaryState.checkedCount0)}}}两种方案怎么选方案好处风险Param Event链路直观适合父子组件层级深时参数搬运多Provider Consumer减少中间层转发容易被滥用成全局状态独立 Store/Repository适合业务数据UI 状态过度下沉会变复杂我的选择是父子之间优先 Param/Event跨三层以上、多个组件都要读写的 UI 状态再用 Provider/Consumer持久化业务数据不要直接塞进去还是走 Repository。本地怎么验证Demo 里我验证两个结果。第一深层空态按钮清空筛选后顶部工具条和列表条件同时变化第二底部统计更新时不影响筛选状态。classProviderConsumerProbe{filter:RecipeFilterStatenewRecipeFilterState()summary:CheckoutSummaryStatenewCheckoutSummaryState()clearFromDeepChild():void{this.filter.reset()}checkTwoStoresSeparated():boolean{this.summary.update(2,5)returnthis.filter.keywordthis.summary.checkedCount2}}验证通过以后我才会把这种共享方式写进页面规范。它解决的是跨层参数搬运不是所有状态管理问题。以后怎么避免使用 Provider/Consumer 前先写一句话这个状态为什么必须跨层共享如果答案只是“少传几个参数”先不要用。只有中间层完全不关心、深层组件确实需要读写、状态模型又能保持很小才适合上这个能力。我会留下的排查清单这类问题以后不要只靠肉眼看页面是否正常。第一步先把状态来源写清楚它来自页面自己、父组件输入、跨层共享还是异步任务返回。第二步把触发动作写清楚用户点击、数据刷新、页面切换、组件重新激活分别会改哪些字段。第三步看刷新范围当前可见 UI 是否刷新不可见组件是否被带着刷新派生计算是否重复执行。第四步再看副作用请求、数据库写入、日志统计和缓存更新有没有被误放到 UI 派生逻辑里。我更建议把这些检查沉到项目代码评审里。以后遇到类似问题先按“复现动作、状态归属、解决方案、验证结果、如何避免”五项过一遍如果其中一项说不清楚就不要急着把新 API 写进正文或提交到项目里。这样文章能解释清楚代码也能经得起下一次改需求。还有一个实际取舍如果 Demo 写完以后发现解释全靠口头补充说明这个方案还没有封装好。能抽成一个小工具、一个组件、一个 controller 或一条项目规则才说明它不是临时补丁。文章里也应该把这个取舍讲出来让读者知道什么时候照着用什么时候应该换方案。最后再补一次边界验证改动前后都要保留最小复现步骤方便后面版本升级时重新跑一遍。
