安全调用Pinia需通过getter/action操作、确保store初始化与持久化、异步权限加载后决策、登出清理收口于store；避免直读$state、绕过action或手动操作localStorage。
在 Vue Router 路由守卫中安全调用 Pinia 仓库，核心是“不绕过 store、不直读原始状态、不忽略异步时机”。守卫不是状态操作入口，而是状态驱动的决策节点——所有读写都应通过 store 提供的 getter 和 action 封装完成，且必须处理初始化与加载延迟问题。
确保 store 已初始化并恢复持久化数据
页面刷新后，Pinia 默认不会自动从 localStorage 恢复 token 或权限。若未配置 pinia-plugin-persistedstate 或未在 store 中手动读取，useUserStore().token 可能为空，导致守卫误判未登录。
- 在 store 定义时，state 初始化就应尝试从 localStorage 获取关键字段：
token: localStorage.getItem('token') || '' - 使用插件时，明确指定持久化哪些字段，例如：
persist: { key: 'user', paths: ['token', 'roles', 'userInfo'] } - 避免在守卫里写
if (!store.token) { ... }，而应依赖store.isLoggedIn这类封装好的 getter，它内部已整合了非空 + 有效时间校验逻辑
在守卫中只读取 getter，不直接访问 $state
Pinia 的 $state 是响应式代理对象，但它的属性可能尚未被异步填充（比如权限列表还在请求中）。直接读 store.$state.roles 容易拿到空数组或 undefined，引发鉴权跳转错误。
Springboot Vue Builder
下载
从零开始编排 SpringBoot+Vue 全栈项目工作流，适用于新建全栈项目或完整脚手架请求，触发后依次调用 product‑spec‑builder（需求调研）等模块。
- 统一通过 getter 判断：如
store.hasRole('admin')或store.hasPermission('order:delete')，这些方法内部会检查isPermissionsLoaded状态 - 需要获取原始数据时，也优先用 getter 封装：比如
store.currentRoles返回的是经过过滤和去重后的角色列表，而非裸露的state.roles - 不要在守卫里写
store.roles = [...newRoles]—— 修改必须走 action，例如store.setRoles(newRoles)
异步权限加载需配合 next() 控制导航流程
当用户已登录但权限尚未拉取（常见于首次进入 /dashboard），守卫不能直接放行或拦截，而要等待权限加载完成再决策。
- 先检查
!store.isPermissionsLoaded，若为 true，则调用await store.fetchPermissions() - fetchPermissions() 应返回 Promise，并在 resolve 后触发动态路由注册（如
router.addRoute()） - 调用
next()前确保权限已就绪；若想显示 loading，可用next({ name: 'Loading' })跳转中间页，再由该页监听 store 加载完成后再重定向 - 避免在守卫中用
setTimeout或轮询判断，这会破坏响应式流，也难以控制竞态
登出与 Token 失效场景下主动清理并重定向
Token 过期、401 响应或用户点击退出时，守卫可能正在执行。此时需在 store 的 logout action 中做完整清理，再由守卫感知状态变化并跳转。
- logout action 必须同步清空
token、roles、userInfo，并移除 localStorage 对应项 - 在全局前置守卫中监听
!store.isLoggedIn，对需认证的路由（meta.requiresAuth === true）强制跳转登录页 - 对敏感路由如
/admin/settings，可在守卫中额外加一层细粒度校验：if (!store.hasPermission('settings:edit')) next('/403') - 不要在守卫里手动删 localStorage —— 清理逻辑应唯一收口在 store 的 action 中，保证一致性
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
