集中式状态管理与组件事件通信是分层协作关系：状态管理负责共享数据的统一持有和变更（如用户信息、购物车），事件机制仅用于局部行为通知（如delete:address、validate:error），二者通过“事件触发→store变更→UI响应”协同，严禁双向耦合或越界传递数据。
集中式状态管理与组件事件通信不是非此即彼的选择，而是分层协作的关系：状态管理管“数据归属”，事件机制管“行为触发”。关键在于明确边界——哪些该进 store，哪些只该 emit。
状态管理负责共享数据的统一持有和变更逻辑
当多个模块（如订单页、购物车浮层、用户中心）都需要读写同一份数据（如当前用户信息、购物车商品列表、全局主题配置），就该交由 Pinia 或 Vuex 统一维护。
- store 中定义清晰的 state、actions 和 getters，所有修改必须通过 actions 触发，确保可追踪、可回溯
- 组件只调用 store 方法（如 store.addToCart(item)），不直接操作原始数据
- 对副作用敏感的操作（如添加商品后自动拉取优惠券、提交订单后清空本地缓存）在 actions 内封装，避免散落在各组件中
组件事件用于局部行为通知，不携带业务状态
事件通信依然不可替代，但它应退回到“通知”本质——告诉其他方“某件事发生了”，而不是“把数据塞过去”。
- 子组件点击“删除地址”按钮，emit delete:address，父组件或监听者决定是否调用 store.deleteAddress(id)
- 表单子组件校验失败时 emit validate:error，由父容器统一滚动到错误区域或弹出提示，而非把整个 errors 对象传出去
- 避免 emit 大量结构化数据（如整个 user 对象），那说明状态本该在 store 里
两者协同的关键实践：事件触发状态变更，状态变更驱动 UI 响应
典型流程是：用户操作 → 组件 emit 行为事件 → 父/容器组件捕获 → 调用 store action → store 更新 state → 所有订阅该 state 的组件自动响应。
- 例如“切换语言”：语言选择器 emit lang:change → Layout 组件监听并执行 i18nStore.setLang(code) → i18nStore 内部更新 locale 并触发 $patch → 所有使用 t() 的组件实时刷新
- 不推荐做法：选择器直接调用 store，绕过事件层——这会让 UI 组件和 store 强耦合，难以复用或测试
- 也不推荐反向操作：store 主动 emit 事件通知组件——这破坏了单向数据流，容易引发循环更新
跨模块场景下的分层建议
按数据变化频率和影响范围划分职责：
- 高频、多模块共读写（如登录态、购物车、消息未读数）→ 进 Pinia，配合 $subscribe 做跨模块副作用
- 低频、单点触发、需精确控制流向（如弹窗关闭回调、步骤条跳转、编辑模式切换）→ 用 defineEmits / mitt，命名带模块前缀（modal:close、form:submit）
- 只读上下文类数据（如 API baseURL、主题色变量、权限配置）→ provide/inject，不走 store 也不 emit，轻量且语义明确
