Pinia 状态管理：模块化、持久化与“权限联动”落地

Pinia 状态管理模块化、持久化与“权限联动”落地很多项目上 Pinia 不难用但容易用成两种极端全部状态都塞进 store组件越来越“胖”store 只存 token其它状态各自维护协作成本变高这篇按“项目落地”的方式讲 Piniastore 如何分模块领域边界state/ getter / action 如何设计可维护持久化存什么、不存什么安全与一致性与 Axios 拦截器、权限路由怎么联动成闭环目标是写出来的 store 不仅能跑还能在项目迭代中长期稳定。1. Pinia 在项目里解决什么问题跨页面共享状态登录态、用户信息、字典、主题配置减少 props/emit 链路避免层层传递统一副作用入口把“请求 缓存 失效”放在 store action2. store 怎么分模块建议的边界按“领域”拆而不是按“页面”拆useUserStoretoken、用户信息、角色/权限、登出useAppStore主题/布局、侧边栏折叠、全局 loadinguseDictStore字典缓存下拉框、枚举避免为每个页面新建一个 store复用差、维护重3. 选项式 vs 组合式先统一团队写法Pinia 支持两种写法选项式Options Store更像 Vuex结构清晰组合式Setup Store更贴近 Composition API可自由组合逻辑建议团队里统一一种写法避免同一项目两套风格混用。4. 一个实用的userstore 形态建议做成“登录态权威源”import{defineStore}frompiniaexportconstuseUserStoredefineStore(user,{state:()({token:,userInfo:nullasnull|{id:number;name:string;role:string},}),getters:{isLogin:(s)!!s.token,role:(s)s.userInfo?.role,},actions:{setToken(token:string){this.tokentoken},setUserInfo(info:any){this.userInfoinfo},asynclogout(){this.tokenthis.userInfonull},},})建议让“读状态”都从 getters 出口走组件依赖更清晰action 负责副作用请求、缓存、失效5. 持久化token/用户信息怎么存更稳常见做法仅持久化tokenuserInfo在刷新后重新拉取更可信、更安全如果你希望持久化例如减少首屏请求至少做到token 过期后要能自动清理角色变化后要能“强制刷新权限”持久化插件的接入方式很多这里核心是原则不强调具体库。工程建议更稳只持久化 tokenuserInfo 在刷新后重新拉取避免角色变化、权限变更导致前端缓存“过期”登出时清理 token 并重置所有权限相关 store6. Pinia 和 Axios 拦截器联动典型目标请求头自动携带 token401 统一踢下线/跳登录伪代码示意axios.interceptors.request.use((config){constuserStoreuseUserStore()if(userStore.token)config.headers.AuthorizationuserStore.tokenreturnconfig})axios.interceptors.response.use((res)res,(err){if(err.response?.status401){constuserStoreuseUserStore()userStore.logout()router.replace(/login)}returnPromise.reject(err)})关键点让“登录态失效”的处理在一个地方收敛store 只做状态与动作路由跳转由响应拦截器或路由守卫兜底7. Pinia 和权限路由联动动态菜单/路由常见需求不同角色展示不同菜单路由守卫按角色放行/拒绝落地方式userStore.userInfo.role作为权限源permissionStore.routes作为可访问路由表登录后拉取用户信息 - 生成动态路由 -router.addRoute建议动态路由生成要可重入刷新、重新登录都能跑一遍退出登录要清理动态路由与缓存菜单工程落地的关键点userStore 只负责“登录态、用户信息、权限源数据”permissionStore 负责“根据权限源生成可访问路由/菜单”路由守卫负责“什么时候生成、什么时候注入、什么时候重建”8. 常见坑反模式清单组件外直接解构 store会丢响应把接口响应原样塞进 store字段不稳定后续很难维护登录态与权限不同步只持久化 token没刷新 userInfo 导致“菜单错乱”再补两个非常常见的坑store 里放 UI 临时状态例如某个弹窗开关会导致 store 膨胀、依赖混乱action 里直接 return 后端原始结构页面不得不写兼容逻辑违背“契约”9. 总结Pinia 的价值在“状态与副作用统一收敛”store 以领域拆分不要按页面拆token 持久化用户信息建议刷新后重新拉取结合 Axios 拦截器与路由守卫实现登录态与权限的闭环