每次页面/标签页加载时刷新access和refresh token是否合理？

这个方案在小流量场景下能跑通，但确实存在几个不可忽视的设计缺陷，不算最优实践：

• 平白增加服务端无效负载
  只要用户刷新页面、打开新标签就触发双Token刷新，会产生大量冗余请求：旧Token本身还在有效期内，完全不需要替换。如果你的服务端做了Refresh Token轮换、黑名单校验、会话绑定逻辑，每一次无效刷新都要额外做一次存储读写，用户量上来之后这部分请求会白白消耗鉴权服务的性能，没有任何实际收益。
• 多标签页场景下极易触发竞态bug
  举个很常见的场景：用户快速连续打开2个同站点标签页，第一个标签页发起刷新请求后，服务端会把旧Refresh Token标记为作废，签发新Token；这时候第二个标签页的刷新请求才发出去，携带的还是本地存储的旧Refresh Token，会直接被服务端判定为无效，轻则刷新失败，重则触发风控把用户踢回登录页。你目前觉得运行良好，大概率是还没碰到这类极端操作场景，这个问题复现概率不高，但一旦出现用户会觉得完全不可理喻。
• 削弱了双Token机制本身的安全设计
  双Token的核心设计思路本来是：Access Token有效期短（通常10-30分钟），就算被窃取攻击者也只有极短的利用窗口；Refresh Token有效期长、只在刷新接口流转，暴露面尽可能小。你现在把Refresh Token的调用频率拉高到每次开页面就传一次，等于大幅增加了Refresh Token被XSS攻击窃取的概率。而且如果你没有做「旧Refresh Token复用触发异常告警」的配置，真出现Token被盗的情况，攻击者和正常用户一样每次打开页面就刷新Token，你根本没法通过异常行为识别到账号失陷。
• 弱网场景下会出现无意义的登出
  如果用户打开页面时刚好断网，刷新请求直接失败，要是你逻辑里写了刷新失败就清除登录态，那用户本地明明还有没过期的Access Token，本来可以正常浏览已加载的页面内容，结果直接被强制退登，体验非常差。

如果你不想等接口返回401再被动刷新Token，完全可以用更稳妥的主动刷新方案替代当前设计，不需要靠每次页面加载全量刷：

• 给Access Token设置提前刷新阈值，比如有效期15分钟的Token，本地解析到剩余有效期不足5分钟时，再主动调用刷新接口
• 多标签页之间通过BroadcastChannel或者localStorage变更事件做同步，同一时间只允许一个标签页发起刷新请求，避免竞态
• 加最短刷新间隔锁，比如距离上次成功刷新不足10分钟时，即便打开新标签页也不触发重复刷新

简单说，你现在的方案本质是靠牺牲性能、部分场景稳定性和安全性，换前端逻辑的简单实现，个人项目、内部小系统用着没问题，但面向C端的大流量项目不建议这么设计。

内容的提问来源于stack exchange，提问作者Gnopor