Pinia 实现模块化数据共享的核心是通过 storeToRefs 保持响应式、$subscribe 监听状态变更、defineStore 抽离共享逻辑层，并谨慎使用 $state 跨模块写入。
模块化 Store 实现数据共享，核心在于打破模块边界，让状态可被安全、可控地跨模块读取与响应。Vue 3 的 Pinia 是目前最推荐的方案，它天然支持模块化，且通过
storeToRefs
、
getActivePinia()
和
defineStore
的灵活组合，能优雅解决跨模块访问问题。
用 storeToRefs 保持响应式引用不丢失
直接解构 store 属性会丢失响应性，这是常见陷阱。正确做法是先用
storeToRefs
提取响应式引用，再在其他模块中使用：
在 userStore 中定义
和
在 orderStore 中 import userStore，调用
后续任何对
的读取或 watch 都能自动响应变化
通过 $subscribe 监听其他模块状态变更
当某个模块需要“感知”另一模块的状态更新（比如用户登出时清空购物车），可用
$subscribe
订阅目标 store 的变更：
在 cartStore 中调用
注意过滤 mutation 类型和 payload，避免误触发
订阅默认不持久，组件卸载时需手动
或使用 onBeforeUnmount 清理
用 defineStore 创建共享逻辑层（非持久 state）
对于多个模块共用的计算逻辑或派生状态（如权限判断、全局 loading 状态），建议单独抽离为一个“逻辑 store”，不存放原始数据，只封装方法和 getters：
新建
，用
各业务模块按需导入并使用
，无需重复判断
这种写法清晰分离关注点，也便于单元测试
谨慎使用 $state 直接修改 —— 跨模块写入需约定规范
虽然技术上可通过
修改其他模块状态，但强烈建议仅限于极少数场景（如全局错误重置、主题切换）：
必须配套文档说明修改时机与副作用
优先用 action 封装变更逻辑，例如
内部统一清理 user、cart、notification 等相关状态
避免在组件中散落跨模块赋值，否则调试和维护成本陡增
模块间数据共享不是越自由越好，而是要在解耦与协同之间找平衡。用好 Pinia 的响应式穿透能力、订阅机制和逻辑抽象，比强行“打通所有模块”更可持续。
userInfoisLoggedInconst { isLoggedIn } = storeToRefs(useUserStore())isLoggedInuseUserStore().$subscribe((mutation) => { if (mutation.storeId === 'user' && mutation.type === 'patch object' && !mutation.payload.isLoggedIn) clearCart() })unsubscribesharedLogic.tsdefineStore('shared', () => { const user = useUserStore(); const cart = useCartStore(); return { canCheckout: computed(() => user.isLoggedIn && cart.items.length > 0), isLoading: computed(() => user.$state.loading || cart.$state.loading) } })sharedLogic.canCheckoutuseOtherStore().$state.xxx = newValueuserStore.logoutAndResetAll()