状态提升是将共享状态提至最近共同父组件管理的解法，适用于兄弟组件依赖同一数据、跨多层prop传递冗余、需统一控制状态生命周期三类场景。
状态提升是解决多子组件通信最直接、最可控的方式——它不靠黑盒机制，而是把共享逻辑显式地“托举”到它们共同的父组件中管理。
为什么提升能打破通信僵局
多个子组件之间没有天然联系，硬要让它们互相读写状态，要么引入全局变量破坏封装，要么用事件总线增加隐式依赖。而共同父组件天然具备“调度权”：它知道谁在变、谁需要响应、什么时候该同步。
比如一个表单页里有输入框、实时校验提示、提交按钮三个组件，它们都依赖“当前输入是否有效”这个判断。如果各自维护判断逻辑，就会出现状态不一致；而把校验结果（或原始值）提到父组件，三者就自然对齐了。
怎么识别该提升的状态
关键看三点：
- 谁决定它该变：不是“哪个组件用了它”，而是“哪个组件有权改变它”。例如全选按钮点击后，所有复选框状态应随之更新——那“全选状态”就该由父组件控制
- 是否被多个组件消费：搜索关键词被列表、筛选栏、分页器同时使用，这就是典型共享状态
- 是否需统一生命周期管理：如重置表单、撤销操作、批量保存前校验——这些动作天然属于组合层，不该分散在各子组件里
父组件如何组织和分发
提升不是简单挪个 ref，而是建立清晰的契约：
-
用 v-model 或自定义 modelValue 封装语义：如
<filterpanel v-model="filters"></filterpanel>，子组件内部处理增删逻辑，外部只关心最终值 -
子组件只 emit 事件，不直接改父状态：触发
update:filters而非试图修改props.filters，保持响应式链完整 -
派生状态交给 computed：比如已选数量、是否可提交、是否有未保存变更——这些都应在父组件里用
computed计算，避免重复逻辑散落各处
什么情况下别硬提
状态提升有边界：
- 当父组件开始堆砌大量无关状态、方法，明显承担了不该管的职责时，说明层级太浅，该考虑
provide/inject（适合深层主题、配置类上下文） - 当状态需要跨路由、跨模块持久化，或要支持时间旅行调试时，就该交由 Pinia 等状态库管理
- 临时性、低耦合的通知（如 Toast 提示、快捷键触发），用事件总线更轻量，不必强拉进状态流
