pinia通过扁平化store设计与组合式api实现响应式状态管理解耦：每个业务域建独立store，命名语义化；用definestore函数式写法聚合状态、计算属性与异步逻辑；storetorefs保持响应性；按需加载+目录隔离强化运行时与构建时解耦。
响应式状态管理解耦的关键，不是把状态藏得更深，而是让每个状态单元职责清晰、边界明确、按需加载。Pinia 的扁平化 Store 设计天然支持解耦，而组合式 API 则让这种解耦在代码层面真正落地——状态、逻辑、副作用不再分散，也不强绑定于组件生命周期。
用独立 Store 替代全局状态对象
避免在 main.ts 或全局 const 中维护裸露的响应式变量（如 export const userInfo = ref({})），这类写法无法被 Vue 的依赖追踪系统识别变化，组件也不会更新。
- 每个业务域建一个 Store：用户、权限、订单、配置各成一体，互不侵入
- Store 名称即语义：如
useAuthStore不叫useGlobalStore，避免“万能筐”倾向 - Store 内部只暴露必要字段和方法，不导出原始
ref或reactive对象供外部直接修改
在 Setup Store 中聚合关注点
采用 defineStore(..., () => {...}) 的函数式写法，把同一业务的状态、计算属性、异步逻辑写在一起，而不是拆到 options 的不同字段里。
- 用
ref和computed定义状态与派生值，类型推导自然完整 - actions 中可混合同步赋值与
await，无需区分 mutation/action - 可直接使用
watch、onMounted等组合式 API 做副作用控制，比如监听 token 变更后刷新用户信息
解构时保留响应性：用 storeToRefs
直接解构 Store 返回的对象会丢失响应式，例如 const { count, increment } = useCounterStore() 中的 count 变成普通数字。
- 对需要响应式的 state 和 getters，统一用
storeToRefs(store)提取 - actions 方法可直接解构，它们本身是普通函数，不依赖响应式上下文
- 示例：
const { count, doubleCount } = storeToRefs(counterStore)，后续count.value更新，视图自动同步
按需加载 + 目录取舍强化解耦
解耦不仅是逻辑分离，更是构建时和运行时的资源隔离。
- 将 Store 按模块拆到
src/stores/modules/下，如user/、cart/，每个目录含index.ts（store定义）、types.ts（接口）、api.ts（请求封装） - 路由级懒加载 Store：在
defineAsyncComponent或onBeforeRouteEnter中动态引入对应 Store，首屏不加载无关状态 - 禁用全局挂载：不通过
app.config.globalProperties.$store注入，所有 Store 都显式导入使用，调用关系一目了然
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
