第3章 Vue组件通信与状态管理（Vuex/Pinia）

是否具备 完整的通信知识体系；能否根据场景（关系类型、项目规模、团队规范）做出合理的技术选型；是否了解 Vue 3 对通信方式的演进（mitt 替代 Event Bus、Pinia 替代 Vuex）。

分类列举 → 场景匹配 → 选型原则 → 演进说明。先按「父子 / 兄弟 / 跨层 / 全局」四类列出方案，再给出“小型项目优先 props+emit，中大型引入 Pinia”的选型建议，最后点出 Vue 3 的推荐变化。

Vue 通信分四类：父子用 props/emit；兄弟推荐 mitt；跨层用 provide/inject；全局状态用 Pinia。选型原则：小项目从简，先 props 后 Bus；中大型直接上 Pinia，按模块拆分 store，兼顾可维护性与 TS 支持。

① provide/inject 的数据不是响应式的，如何让它响应式？
② mitt 与 Event Bus 相比有什么优势？
③ 如果项目已经用了 Vuex，迁移到 Pinia 的成本和收益如何评估？

❌ 不要只罗列方案而缺少选型判断。
❌ 不要忽略 Vue 3 对 Event Bus 的废弃，建议主动提 mitt。
❌ 不要把 provide/inject 当作全局状态管理滥用。

对 Vue 生态状态管理工具的 深度理解与对比分析能力；是否关注过 Pinia 的设计理念（Composition API、TypeScript 优先）；能否在面试中给出技术选型的合理建议。

设计理念 → API 差异 → TS 支持 → 体积与体验 → 迁移建议。核心对比点：Pinia 去掉了 mutation、模块无需嵌套、天然 TS 支持、体积更小。适合 Vue 3 新项目直接选用。

Pinia 相比 Vuex 有三点核心升级：① 去掉 mutation，action 直接修改 state，代码量减少 30%；② 模块化无需 namespace 嵌套，每个 store 独立定义；③ 天然支持 TS 类型推断，开发体验更好。Vue3 新项目首选 Pinia。

① Pinia 中如何实现类似 Vuex 的 mutation 日志或时间旅行调试？
② 在 Pinia 中如何实现模块间的相互调用？
③ Pinia 的 $reset 方法在 setup 语法中为什么不可用？

❌ 不要简单说「Pinia 是 Vuex 的替代品」，要强调设计理念升级。
❌ 不要忽略 Pinia 对 Composition API 的原生适配。
❌ 不要回答「Pinia 没有 mutation」，可以补充说明其设计取舍。

对 异步流程控制 的理解；是否清楚 Vuex 中 action 与 mutation 的职责分离，以及 Pinia 在异步场景下的简化设计；能否处理竞态、错误恢复等真实问题。

Vuex 异步方案 → Pinia 异步方案 → 核心差异 → 最佳实践。关键点：Vuex 通过 action 提交 mutation 触发状态更新；Pinia action 可直接修改 state，更简洁。两者都支持 async/await 与 try-catch 错误处理。

Vuex 中 action 返回 Promise，内部 commit mutation 更新 state，常用于接口请求后触发状态变更。Pinia 更直接：action 里用 async/await 请求数据，直接赋值给 state，省去 mutation 层。两种都推荐配合 loading/error 状态管理，提升健壮性。

① 如何取消一个正在执行的异步 action？（AbortController）
② 多个异步 action 之间有依赖关系时如何编排？（action 组合 / store 互调）
③ 如何处理异步请求的竞态问题？（请求序列号 / 取消过期请求）

❌ 不要忘记 Vuex 中 mutation 必须是同步的。
❌ 不要把异步逻辑写在 getter 里。
❌ 不要忽视错误处理——面试中提及「