权限缓存设计与实现中的常见问题与优化策略

我的写法，亲测靠谱

权限缓存这事，我前后在三个项目里折腾过：一个中后台系统（Vue 2 + 后端 RBAC）、一个 SaaS 多租户管理台（React + 权限策略动态加载）、还有一个小程序后台（uni-app + 自研权限 SDK）。每次上线后都出过问题，不是菜单突然没了，就是按钮该禁用却点开了，最离谱的一次是用户刷新页面后能访问未授权接口——查了两天才发现是缓存没清干净。

最后稳定下来的方案其实很朴素：不搞 fancy 的全局响应式权限对象，也不依赖 Vuex/Pinia 的自动订阅更新。我就用一个纯 JS 对象 + localStorage + 显式触发机制。核心代码就这几行：

// permission-cache.js
const PERMISSION_KEY = 'user_permissions_v2'

export const PermissionCache = {
  get() {
    try {
      const raw = localStorage.getItem(PERMISSION_KEY)
      return raw ? JSON.parse(raw) : null
    } catch (e) {
      console.warn('权限缓存解析失败，清空', e)
      this.clear()
      return null
    }
  },

  set(permissions) {
    if (!Array.isArray(permissions)) {
      console.error('权限必须是数组，当前类型：', typeof permissions)
      return
    }
    try {
      localStorage.setItem(PERMISSION_KEY, JSON.stringify(permissions))
    } catch (e) {
      // 超出 quota 时静默降级，不阻断主流程
      console.warn('权限缓存写入失败，跳过', e)
    }
  },

  clear() {
    localStorage.removeItem(PERMISSION_KEY)
  },

  // 关键：这个方法必须被显式调用，绝不自动触发
  refreshFromServer() {
    return fetch('https://jztheme.com/api/v1/permissions', {
      credentials: 'include',
      headers: { 'X-Requested-With': 'XMLHttpRequest' }
    })
      .then(res => {
        if (!res.ok) throw new Error(HTTP ${res.status})
        return res.json()
      })
      .then(data => {
        if (Array.isArray(data?.permissions)) {
          this.set(data.permissions)
          return data.permissions
        }
        throw new Error('权限接口返回格式异常')
      })
  }
}

为什么这样写？因为权限不是「状态」，而是「决策依据」。我踩过太多坑：比如把权限存在 Vue 响应式 data 里，结果组件渲染时读的是旧值；又或者用 computed 依赖某个 store 字段，但 store 更新延迟了 200ms，中间那段时间按钮就裸奔了。现在所有组件里判断权限，我都直接调 PermissionCache.get().includes('user:delete') —— 没有订阅、没有异步等待、没有 race condition。简单粗暴，但稳定。

这几种错误写法，别再踩坑了

下面这些，都是我在 code review 或线上日志里反复看到的雷：

• 用 Date.now() 当缓存 key 做“伪刷新”：
  有人觉得加个时间戳就能强制更新，于是写成 fetch(/api/perm?_t=${Date.now()})。问题在于：前端时间不准，服务端可能开了 CDN 缓存，而且根本没解决 localStorage 里的脏数据问题。用户退出重登后，旧权限还在本地，新权限只刷了一次接口，但组件还是读 localStorage。
• 在路由守卫里做权限校验，却不检查缓存有效性：
  比如 router.beforeEach 里直接读 localStorage 判断是否有权限，但没验证这个缓存是不是 3 小时前的。更糟的是，有些团队还把权限检查和 token 过期混在一起处理，token 没过期就默认权限也没变——错！RBAC 权限可能被管理员秒删，跟 token 毫无关系。
• 用 sessionStorage 存权限：
  理由是“关掉标签页就自动清掉”，听起来安全？但实际中用户经常 Ctrl+T 关错标签，或者从收藏夹新开页面，sessionStorage 就丢了，一刷新直接白屏或 403。我们线上有个客户反馈“点了菜单没反应”，最后发现是他们习惯开两个标签页操作，一个关了另一个还在用，但权限没了。现在一律用 localStorage + 显式清除逻辑。
• 把权限字符串硬编码进组件里做判断：
  比如 v-if="hasPermission('order:export')"，看着清爽，但问题是：这个字符串散落在十几个文件里，哪天后端改了权限码（比如从 order:export 改成 order:download），你得 grep 全局，还容易漏。我现在统一收口到一个 PERM 对象里：

  export const PERM = {
    USER_DELETE: 'user:delete',
    ORDER_EXPORT: 'order:download',
    DASHBOARD_ANALYTICS: 'dashboard:analytics'
  }

  组件里只写 v-if="hasPermission(PERM.ORDER_EXPORT)"，改名只动一处。

实际项目中的坑

真实场景永远比文档复杂：

坑一：多标签页同步问题
用户开着两个 tab，A 标签页里管理员给他加了权限，B 标签页不知道。我试过 storage 事件监听，但兼容性差（Safari 移动版不触发），而且事件可能丢失。最后妥协方案：在关键操作前（比如点击导出按钮）先 check 一遍权限，如果本地没这个码，立刻 refreshFromServer()，成功后再执行操作。加个 loading 状态，用户感知不强，但比白屏友好得多。

坑二：权限粒度太细导致性能崩
有次后端给的权限列表有 800+ 条（每个按钮、每列字段都单独一条），localStorage 存取开始卡顿。我被迫加了个预处理：前端只存 action 级别权限（user:create, user:read），字段级权限（如 user.phone:visible）由后端在数据返回时带上，前端不缓存。省下 700 行，localStorage 写入快了 5 倍。

坑三：SSR 下的水合 mismatch
用 Nuxt 的项目里，服务端渲染时拿不到 localStorage，只能 fallback 到空数组，结果客户端 hydrate 时权限突然出现，UI 跳变。解决方案很土：服务端完全不渲染权限相关 DOM，全交给客户端 mount 后根据 PermissionCache.get() 动态插入。牺牲一点 SEO，换来稳定。

以上是我总结的最佳实践，有更优的实现方式欢迎评论区交流。权限缓存这事，没有银弹，只有权衡。我这套目前跑得稳，但如果你有更好的方案（比如用 IndexedDB 做带版本的权限存储），求分享！