关键是在路由守卫中通过 Pinia store 统一维护权限，守卫只调用 store actions 或 getters 进行鉴权决策，不直接修改状态；需检查权限加载状态、动态添加路由、确保初始化同步，并在 login action 中统一处理权限获取与存储。
在路由守卫中读取和修改用户权限状态，关键不是“读取后改一改”，而是通过 Pinia store 统一维护权限数据，并在守卫中触发校验、动态加载或强制更新逻辑。守卫本身不直接修改权限（比如不手动赋值 roles 数组），而是调用 store 提供的 actions 或依赖其 getters 做判断。
从 store 中安全读取权限信息
守卫里应始终通过 useUserStore() 获取最新状态，而不是读 localStorage 或 cookie：
- 调用 userStore.getRoles() 或 userStore.permissions（getter）获取当前角色/权限列表
- 避免直接访问
userStore.$state.roles，以防未初始化或异步加载未完成；推荐封装 getter，例如：getters.hasRole = (role) => state.roles?.includes(role) - 若权限是异步拉取的（如登录后请求 /api/user/permissions），需先检查
userStore.isPermissionsLoaded，未加载完可next(false)暂停导航，或显示 loading 状态
根据权限决定是否放行或重定向
守卫的核心职责是“鉴权决策”，不是“赋值”：
Skill Weave Chains — 技能链路由引擎
下载
开箱即用的技能链路由引擎。13 条预定义链覆盖搜索、开发、审查、MLOps、法律、创意等场景，三层路由架构（触发词→SAD反馈→DAG编排），recall@10=96.97%。配置驱动（chains.yaml），零代码扩展。pip install skill-weave-chains 一键安装。
- 检查目标路由 meta 是否有
requiresAuth: true，若未登录（!userStore.isLoggedIn），跳转至登录页并缓存to.fullPath - 检查 meta.roles 或 meta.permissions，用 hasRoles(userRoles, to.meta.roles) 判断匹配性；不匹配则跳转 403 页面
- 对敏感操作路由（如 /admin/users/edit），可在守卫中额外校验细粒度权限，例如
userStore.hasPermission('user:edit')
需要时触发权限刷新或动态路由添加
权限变更（如切换角色、token 刷新成功）常发生在守卫执行过程中，这时要调用 store 方法驱动更新：
- 用户已登录但
userStore.roles.length === 0，说明权限未加载，可调用userStore.fetchPermissions()（返回 Promise），然后await next()等待完成 - 权限加载完成后，若使用前端静态路由表，需调用
router.addRoute()动态注册菜单对应路由；store 中可暴露addDynamicRoutes(routes)action 封装该逻辑 - 登出或 token 失效时，在守卫中调用
userStore.logout()，该 action 应清空 roles、token 并移除 localStorage，再跳转
注意守卫执行时机与状态同步
避免因状态滞后导致误判：
- 确保 store 初始化时已从持久化存储（localStorage / pinia-plugin-persistedstate）恢复 roles 和 token，否则刷新页面后
userStore.roles为空数组 - 不要在守卫里写
userStore.roles = ['admin']这类直接赋值——所有变更必须走 action，保证响应式更新和副作用可控 - 若权限依赖接口响应，建议在 login action 中统一处理：保存 token → 拉权限 → 存入 store → 触发路由重定向，守卫只做“守门人”，不做“搬运工”
