服务端（Next.js等）JWT刷新处理及常见问题咨询

一、并发请求导致刷新令牌失效的处理 #

针对多个请求同时触发刷新令牌的场景，核心是避免重复刷新，确保同一时间只有一个请求能完成令牌轮转：

• 加分布式互斥锁：用用户ID或刷新令牌值作为锁键，借助Redis实现分布式锁。当第一个携带过期JWT的请求进入服务端，先获取锁，执行刷新令牌流程；其他请求等待锁释放后，直接使用已生成的新JWT和刷新令牌，无需再次发起刷新请求，避免因多个请求同时刷新导致旧令牌提前失效。
• 过滤无需鉴权的请求：在自定义服务器或中间件中，只对需要鉴权的API请求、getServerSideProps渲染请求做过期检查和刷新处理；静态资源（JS、CSS、图片等）直接放行，不触发鉴权逻辑，减少触发刷新的请求量。
• 服务端缓存新令牌：刷新完成后，将新的JWT和刷新令牌缓存到Redis（关联用户ID），有效期设为新JWT的过期时间。后续请求进来时，先检查缓存中是否有可用的新令牌，有则直接使用，无需重复刷新。

二、用户未接收响应导致令牌丢失的处理 #

针对用户中途关闭页面、未收到新cookie的场景，核心是降低令牌丢失风险，保留重试机会：

• 给旧刷新令牌设置宽限期：轮转刷新令牌时，不要立即失效旧令牌，而是设置30秒-1分钟的宽限期。在宽限期内，旧令牌仍可用于刷新，但只能生成一次新令牌；宽限期结束后，旧令牌彻底失效。这样即使用户没收到新cookie，也能在宽限期内重新发起刷新请求，避免直接陷入无有效令牌的状态。
• 拆分刷新与业务逻辑的执行顺序：服务端处理请求时，先完成刷新令牌的轮转操作，生成新的JWT和刷新令牌并设置Set-Cookie响应头，再执行耗时的业务逻辑（比如数据库查询）。浏览器会在收到响应头时就更新cookie，哪怕用户中途关闭页面，新cookie已经生效，用户后续发起请求时就能使用新的令牌。
• 记录刷新令牌的过渡状态：用Redis存储刷新令牌的状态，旧令牌标记为“待失效”，新令牌标记为“有效”。如果在一定时间内（比如1分钟），新令牌没有被使用，就恢复旧令牌的有效性。这个方案复杂度稍高，但能应对极端场景下的令牌丢失问题。

针对Next.js服务端场景的额外优化 #

在getServerSideProps中处理刷新时，将鉴权逻辑抽离到中间件或自定义服务器中，完成令牌刷新后，将新的JWT通过req对象传递给getServerSideProps，避免在每个页面的getServerSideProps中重复处理刷新逻辑。同时结合上述分布式锁和缓存机制，确保服务端渲染请求不会触发重复刷新。

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