Pinia 处理多仓库交叉依赖的关键是让依赖清晰可控可维护，提供轻量读取、状态共享、显式通信、协调调度四种方式：直接导入封装调用、抽离共享 ref、通过 actions 显式触发、避免初始化时循环依赖。
Pinia 处理多个仓库之间的交叉依赖，关键不是“禁止调用”，而是让依赖清晰、可控、可维护。它不强制解耦，但提供多种方式让你按需选择——轻量读取、状态共享、显式通信、协调调度，每种都对应不同复杂度的业务场景。
直接导入并封装调用（适合简单读取）
这是最常用也最直观的方式：在 Store A 中 import Store B，并在 getter 或 action 内调用其状态或方法。
- 确保被导入的 Store 已定义完成，不能在 defineStore 内部 import 自身或循环依赖的 Store
- 推荐封装逻辑，比如 OrderStore 需要用户昵称，不要在 setup 里到处写
useUserStore().nickName，而应在 store 内部统一处理：get userName() { return useUserStore().nickName } - 响应式天然成立——userStore.nickName 变了，OrderStore 的 userName 会自动更新
共享基础响应式状态（适合全局配置类数据）
当多个 Store 都需要读写同一份简单、无业务逻辑的状态（如主题色、语言、是否开启调试模式），可抽离为独立的 ref/reactive，避免冗余导入和隐式耦合。
- 新建
shared/state.ts，导出const theme = ref('light')、const locale = ref('zh-CN') - 各 Store 直接 import 使用，变更自动同步，无需额外监听
- 不建议把这类状态放在某个 Store 里再 export —— 容易让其他 Store 对该 Store 产生非必要依赖
通过 actions 显式通信（适合业务联动）
当一个 Store 的动作需要触发另一个 Store 的特定行为（例如修改购物车后刷新订单摘要），应由调用方在 action 中主动调用目标 Store 的 action，而不是偷偷改它的 state。
- 保持单一数据源原则：cartStore 不该直接赋值 orderStore.summary = …，而应调用
orderStore.refreshSummary() - 联动逻辑收束在 action 内，方便加 loading、日志、错误处理或条件判断
- 若跨 Store 调用频繁且路径复杂（如登录 → 拉用户信息 → 初始化购物车 → 加载优惠券），可单独抽一个“流程 Store”或组合式函数（composable）来编排，让职责更清晰
警惕初始化时机与循环依赖
看似合法的 import 链，可能在运行时卡死——这不是语法报错，而是模块加载阶段就失败了。
- Store A 导入 Store B，同时 Store B 又导入 Store A → 循环依赖，启动失败
- 常见诱因：在 defineStore 的 options 对象中 import 其他 Store（尤其用了对象写法的 state/getters），此时模块尚未完全初始化
- 安全做法：所有跨 Store 调用，统一放在 action 函数体内部或 getter 计算时执行，避开 defineStore 初始化阶段
