先把相关概念说清楚

资料入口：

• https://developer.huawei.com/consumer/cn/doc/harmonyos-guides/arkts-custom-components-freeze
• https://developer.huawei.com/consumer/cn/doc/harmonyos-guides/arkts-v1-v2-migration-inner-component
• https://developer.huawei.com/consumer/cn/doc/harmonyos-guides/arkts-new-provider-and-consumer
• https://developer.huawei.com/consumer/cn/doc/HarmonyOS-Guides/arkts-user-defined-arktsnode-buildernode
• https://developer.huawei.com/consumer/cn/doc/harmonyos-guides/arkts-new-computed

这类问题不要先背 API 名称，先看状态从哪里来、经过哪些组件、最后由谁改掉。下面用两个小例子把链路拆开，重点看问题怎么复现、怎么改，以及改完以后怎么验证。

组件层级深了以后，最常见的难受点是参数一路往下传。首页有关键词、分类、排序，外层传给列表，列表传给空态，空态再传给按钮，按钮点击又要回到最外层。代码能写，但后面很难看清谁真正负责这个状态。@Provider和@Consumer可以减少这种中间层转发，不过它也不是随便替代所有参数的全局仓库。

我会先定一条规则：只有多个层级都需要读写、而中间层只是转交的状态，才考虑 Provider/Consumer。普通父子参数继续用 @Param 和 @Event。这样不会把所有状态都塞进一个跨层共享桶里。

什么适合共享，什么不适合

这个表可以避免一个误区：为了省参数，把所有字段都 Provider 出去。那样短期少写几行，长期会失去状态归属。

案例一：筛选条件一路传到底，怎么改

先看旧写法。中间组件本来不关心筛选，只是为了把参数传给更深层组件，不得不接一堆字段。

@ComponentV2struct RecipePage{@Localkeyword:string=''@Localcategory:string='all'build(){Column(){RecipeToolbar({keyword:this.keyword,category:this.category})RecipeListSection({keyword:this.keyword,category:this.category})}}}

如果RecipeListSection下面还有空态、推荐按钮、结果统计，参数会越传越远。更稳的方式是把筛选条件作为跨层共享状态放在页面根部。

@ObservedV2classRecipeFilterState{@Tracekeyword:string=''@Tracecategory:string='all'reset():void{this.keyword=''this.category='all'}}@ComponentV2struct RecipePage{@Provider('filterState')filterState:RecipeFilterState=newRecipeFilterState()build(){Column(){RecipeToolbar()RecipeListSection()}}}

深层组件只消费自己需要的状态：

@ComponentV2struct EmptyActionBar{@Consumer('filterState')filterState:RecipeFilterState=newRecipeFilterState()build(){Row({space:8}){Text(`当前关键词：${this.filterState.keyword||'未输入'}`)Button('清空条件').onClick(()=>this.filterState.reset())}}}

这样写以后，中间层不用再做参数搬运，读写链路也很明确：页面提供筛选状态，深层组件消费筛选状态。

案例二：底部统计也能共享，但不要把它写成大杂烩

购物清单一类页面常有底部统计：已选数量、总数量、估算价格。这个状态列表、底部栏、弹窗都可能要读。如果每层都传，代码会很长。可以共享一个统计模型，但模型要小。

@ObservedV2classCheckoutSummaryState{@TracecheckedCount:number=0@TracetotalCount:number=0update(checked:number,total:number):void{this.checkedCount=checkedthis.totalCount=total}getlabel():string{return`已选${this.checkedCount}项 / 共${this.totalCount}项`}}

我不会把列表数据、筛选条件、弹窗状态、请求状态都放进这个类。它只负责统计。这样底部栏消费它时，刷新范围可控，也不容易出现“改筛选条件把底部统计也带乱”的问题。

@ComponentV2struct CheckoutFooter{@Consumer('summaryState')summaryState:CheckoutSummaryState=newCheckoutSummaryState()build(){Row(){Text(this.summaryState.label)Blank()Button('生成清单').enabled(this.summaryState.checkedCount>0)}}}

两种方案怎么选

我的选择是：父子之间优先 @Param/@Event；跨三层以上、多个组件都要读写的 UI 状态，再用 Provider/Consumer；持久化业务数据不要直接塞进去，还是走 Repository。

本地怎么验证

Demo 里我验证两个结果。第一，深层空态按钮清空筛选后，顶部工具条和列表条件同时变化；第二，底部统计更新时，不影响筛选状态。

classProviderConsumerProbe{filter:RecipeFilterState=newRecipeFilterState()summary:CheckoutSummaryState=newCheckoutSummaryState()clearFromDeepChild():void{this.filter.reset()}checkTwoStoresSeparated():boolean{this.summary.update(2,5)returnthis.filter.keyword===''&&this.summary.checkedCount===2}}

验证通过以后，我才会把这种共享方式写进页面规范。它解决的是跨层参数搬运，不是所有状态管理问题。

以后怎么避免

使用 Provider/Consumer 前先写一句话：这个状态为什么必须跨层共享？如果答案只是“少传几个参数”，先不要用。只有中间层完全不关心、深层组件确实需要读写、状态模型又能保持很小，才适合上这个能力。

我会留下的排查清单

这类问题以后不要只靠肉眼看页面是否正常。第一步先把状态来源写清楚：它来自页面自己、父组件输入、跨层共享，还是异步任务返回。第二步把触发动作写清楚：用户点击、数据刷新、页面切换、组件重新激活，分别会改哪些字段。第三步看刷新范围：当前可见 UI 是否刷新，不可见组件是否被带着刷新，派生计算是否重复执行。第四步再看副作用：请求、数据库写入、日志统计和缓存更新有没有被误放到 UI 派生逻辑里。

我更建议把这些检查沉到项目代码评审里。以后遇到类似问题，先按“复现动作、状态归属、解决方案、验证结果、如何避免”五项过一遍；如果其中一项说不清楚，就不要急着把新 API 写进正文或提交到项目里。这样文章能解释清楚，代码也能经得起下一次改需求。

还有一个实际取舍：如果 Demo 写完以后发现解释全靠口头补充，说明这个方案还没有封装好。能抽成一个小工具、一个组件、一个 controller 或一条项目规则，才说明它不是临时补丁。文章里也应该把这个取舍讲出来，让读者知道什么时候照着用，什么时候应该换方案。

最后再补一次边界验证：改动前后都要保留最小复现步骤，方便后面版本升级时重新跑一遍。