需要全局 Store 的典型场景包括：①用户登录态与权限信息；②全局配置或主题设置；③复杂表单的多步数据聚合；④实时协作类状态。其余如父子传参、局部UI状态、临时缓存等应避免使用。
不一定。Vue 项目完全可以用组件内部状态（ref、reactive、data）解决绝大多数场景，尤其在 Vue 3 的 Composition API 下，逻辑复用和响应式管理已足够灵活。
哪些情况真的需要全局 Store？
核心判断标准是：**状态是否被多个不相关组件共享，且共享逻辑难以通过 props / emits / provide/inject 清晰传递**。
- 用户登录态与权限信息：顶部导航栏、侧边菜单、接口请求拦截器、路由守卫都需要实时读取，且修改需同步影响所有模块
- 全局配置或主题设置：比如深色模式开关、语言切换、API 基础路径，一旦变更需跨数十个组件响应
- 复杂表单的多步数据聚合：例如电商结算页，收货地址、商品清单、优惠券、支付方式分别由不同子组件维护，但最终提交需统一收集
- 实时协作类状态：如在线文档编辑器中的光标位置、选中文本、协同用户列表，需在多个视图间强一致更新
哪些情况其实不该用？
强行上 Vuex 或 Pinia 反而增加理解成本和维护负担。
Element Plus UI Vue3
下载
Element Plus Vue3 桌面组件库。在开发 Vue 3.x 页面时调用，使用 Element Plus 组件（如 el-button、el-input、el-form、el-table 等）。
-
父子组件深度传参就能搞定的：比如弹窗组件接收父级传入的初始值并回传结果，用
defineModel或v-model更直接 - 仅一个组件内部使用的状态：比如搜索框的输入值、折叠面板的展开状态、表格的当前页码——这些属于局部 UI 状态，放 store 是过度设计
-
临时缓存或计算结果：如某个接口返回的列表，只在当前页面展示和筛选，用
computed+ref缓存即可，无需进全局 store - 小型项目（：此时优先跑通逻辑，store 层可后期按需抽离
比 Vuex/Pinia 更轻量的替代方案
不是所有“全局”都等于“用状态库”。有些需求，一行 export const xxxStore = reactive({...}) 就够了。
立即学习“前端免费学习笔记（深入）”；
-
ES 模块单例对象：利用 ES6 模块只初始化一次的特性，导出一个
reactive对象，在任意组件中import使用，天然响应式，无额外依赖 -
provide / inject（带响应式）：适合局部范围的“伪全局”，比如整个业务模块下的所有子组件共享一个过滤条件，父组件
provide后，子孙组件inject即可，不污染全局命名空间 -
自定义 Hook（composable）：把常用的状态逻辑封装成函数，如
useUserSession()，内部用ref或computed管理，各组件按需调用，复用性高、测试友好
Vue 3 时代的一个务实建议
先写组件，再看耦合。当发现三个以上组件频繁通过层层透传 props、反复 emit 事件、或不断重复 fetch 同一数据时，才是引入全局 Store 的信号。不是项目一开始就要搭好 store 目录结构，而是让状态管理的粒度跟着业务复杂度自然生长。
