该用 provide/inject 时适用于功能闭环场景，如表单容器与子项的上下文传递；该用 Pinia 时是数据跨模块、跨路由或影响副作用，如登录态、主题配置等。
深层嵌套组件中做祖孙通信，核心不是“选哪个更高级”，而是看数据的职责范围和变化边界：只在局部功能域内流动、中间层完全不感知的数据，provide/inject 是最轻量自然的选择；若状态需被多个不相关模块（如侧边栏、请求拦截器、顶部导航）共同读写或持久化，才该交给 Pinia 管理。
什么时候该用 provide/inject？
适用于「功能闭环」场景：比如一个表单容器（祖先）与其所有子表单项（孙子、曾孙）、校验逻辑、提交按钮之间的上下文传递。
- 祖先组件用
provide('formContext', reactive({ ... }))暴露响应式对象 - 任意后代直接
inject('formContext')获取，无需 props 逐层透传 - 推荐用
Symbol作 key，避免字符串命名冲突 - 注入值建议包裹
readonly()，防止下游意外修改源头 - 若需更新，提供封装方法（如
submitForm()），而非暴露原始 ref 或 reactive 对象
什么时候该切到 Pinia？
当数据不再局限于某块 UI 区域，而开始跨业务模块、跨路由、甚至影响副作用（如请求头、权限守卫、UI 主题切换）时，provide/inject 就力不从心了。
- 用户登录态、全局主题配置、国际化语言、实时通知计数等，适合抽成独立 store
- 各组件只 import 对应 store（如
const userStore = useUserStore()），调用userStore.logout()即可 - Pinia 天然支持 Devtools 调试、localStorage 持久化、服务端渲染适配，这些是 provide/inject 无法提供的能力
- 不要把所有状态都塞进一个大 store，按业务域拆分（
useCartStore、useSearchStore），再由父组件按需 provide 给子树，兼顾模块自治与作用域控制
别踩的坑：混用与误判
常见错误不是工具选错，而是对数据本质理解偏差。
- 发现多个兄弟组件频繁通过事件总线同步同一份数据？说明这部分状态本该由共同父级 provide，或直接升级为 Pinia store
- 用
$parent或$children强行取值？破坏封装且非响应式，应视为最后手段 - 在 inject 时直接解包
inject('count').value？会丢失响应性，必须保留 ref 引用或 reactive 对象本身 - 把表单校验规则、分页参数这类局部上下文硬塞进 Pinia？造成全局污染、调试困难、tree-shaking 失效
进阶建议：封装可复用的通信 Hook
把高频依赖逻辑（如表单上下文、权限判断、分页控制器）抽成组合式函数，内部自动完成 provide/inject 配对。
- 父组件调用
useFormContext()→ 自动 provide 表单状态与方法 - 子组件调用同名 hook → 自动 inject 并返回解构后的 API
- 既保持语义清晰，又屏蔽底层细节，还能配合 TypeScript 提供完整类型推导
