如何优化Bearer token刷新流程，避免短时间内请求未授权问题

以下是适配你场景的规范落地方案，比现有两个变通方案的适用性更强：

方案1：客户端请求队列+原子切换（无需改造服务端逻辑） #

• 客户端发起refresh-token请求前，先启动临时请求拦截逻辑，这段时间内新产生的所有用户请求全部暂存到内存队列，不直接发送
• 等客户端拿到新令牌、完成本地令牌替换，再依次发送队列里暂存的请求，所有请求自动携带新令牌
• 旧令牌按原有逻辑立即调用remove-old-token删除即可，完全适配「Remember me」场景必须立即销毁旧令牌的要求
• 整个逻辑对上层业务无感知，0.1秒的窗口延迟用户完全察觉不到，不会出现未授权报错

方案2：服务端动态宽限期机制（更规范的服务端侧实现） #

• 服务端收到refresh-token请求返回新令牌后，给旧令牌设置可配置的短有效期宽限期，普通登录场景宽限期设为1~3秒即可，远短于1分钟的临时方案，完全符合安全规范
• 宽限期内旧令牌依然可正常鉴权，窗口内的请求不会被拦截，宽限期到期后服务端自动销毁旧令牌，无需依赖客户端发送remove-old-token请求，避免客户端故障导致旧令牌遗留的安全问题
• 针对勾选「Remember me」的高安全要求场景，直接关闭宽限期，拿到新令牌后旧令牌立即失效，适配不同安全等级的需求

方案3：提前刷新策略（成本最低的优化方式） #

• 不要等令牌有效期剩最后几秒才发起刷新，调整客户端刷新时机为令牌到期前2~3分钟就提前发起refresh-token请求
• 刷新过程中旧令牌还有充足的剩余有效期，即使刷新窗口内的请求携带旧令牌也能正常鉴权
• 刷新完成后客户端直接切换为新令牌，旧令牌按原有逻辑立即删除即可，无需调整其他逻辑

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