可行但关键在同步与响应：需用pinia管理权限状态，动态重建路由、统一指令/函数控制组件权限，并绑定token与角色实时更新请求头。
用单一状态（比如 userRole 或 permissions）驱动权限逻辑是可行的，但关键不在“存什么”，而在“怎么同步”和“怎么响应”。角色切换不是改个变量就完事，必须让路由、菜单、按钮、API 请求等所有依赖权限的地方立刻感知并更新。
状态管理要支持实时重置
不能只靠 localStorage 或普通 ref 存角色。需要一个可响应、可重置、带副作用管理的状态容器：
- 使用 Pinia store 管理用户角色和权限列表，暴露
setRole(role)和resetAuth()方法 -
setRole内部应清空旧路由缓存、重置菜单树、触发权限变更事件 - 避免直接修改
state.role = 'admin'这类裸赋值——它不触发清理逻辑，容易残留上一角色的菜单或接口凭证
路由必须动态重建，不能仅靠守卫拦截
单纯在 router.beforeEach 里判断权限，只能阻止跳转，无法隐藏已加载的菜单或刷新当前页面权限。真正生效需路由级重建：
- 登录/切换角色后，调用
permissionStore.buildRoutes()重新生成符合当前角色的完整路由表 - 用
router.getRoutes().forEach(r => router.removeRoute(r.name))清空旧路由，再逐条addRoute - 配合
next({ path: to.fullPath, replace: true })强制重走导航流程，确保新路由规则立即生效
组件内权限控制要统一入口，避免硬编码
按钮、操作区、敏感字段等不能每个都写 v-if="role === 'admin'"。应封装可复用的判断逻辑：
- 全局注册指令
v-can="['edit', 'delete']"，内部读取 store 中的permissions数组做包含判断 - 提供组合式函数
usePermission()，返回can(action)方法，供 setup 中调用 - 菜单渲染时，用 computed 过滤
menuList.filter(item => item.meta?.roles?.includes(currentRole))，而非在模板里 v-if 堆砌
Token 和请求头必须与角色强绑定
角色变了，但请求仍发旧 token，后端校验就会失败。前端需确保凭证同步更新：
- 切换角色时，不仅更新 store，还要显式调用
axios.defaults.headers.common['Authorization'] = newToken - 监听 localStorage 的
setItem事件（通过重写 + dispatchEvent），当 token 字段变更时自动刷新请求头 - 避免在请求拦截器中每次读
localStorage.getItem('token')—— 单页应用中该值不会自动响应变化，要用 reactive 包裹或事件驱动更新
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
