如果你只想做一件事：先把91网页版的账号登录做稳（一条讲透）

如果你现在只想做一件事，那就把91网页版的“登录态”做稳——把用户在浏览器里的会话持续性和自动恢复做到可靠，不再让用户因为刷新、网络抖动或并发请求而频繁被踢回登录页。一条讲透：用短期 access token + 存在服务端不可读的 refresh token（放 httpOnly cookie）+ 单点刷新队列，构建既安全又稳定的登录态体系。

下面把这条策略拆成可操作的要点和实施细节，照着做，登录问题能解决绝大部分场景。

核心思路（一句话）

• Access token 生存期短、只保存在内存，承担请求认证；refresh token 放 httpOnly+Secure+SameSite 的 cookie，由服务端验证并签发新的 access token；客户端只负责触发刷新且用队列/互斥避免并发刷新。

为什么这样稳？

• 把长期凭证放到 httpOnly cookie，能防止 XSS 盗取；access token 放内存减少持久泄露风险。
• 短期 access token 降低被滥用窗口；refresh 由后端严格校验（包括设备指纹、IP 限制、变更检测）能及时断开异常会话。
• 单点刷新（single-flight）避免并发刷新导致的竞争与重复登录/登出状态不一致。
• 客户端有退路（exponential backoff + 友好提示 + 限权离线模式），用户体验稳定。

实现步骤（落地清单） 1) Token 策略

• access token：有效期短（5–15分钟），签名（JWT 或自定义），只在内存中保存，不写 localStorage/sessionStorage。
• refresh token：有效期长（几天到几个月），仅放在服务端设置的 httpOnly、Secure、SameSite=strict/lax 的 cookie 中，不暴露给 JS。
• 刷新接口：POST /auth/refresh，服务端从 cookie 读取 refresh token，校验并返回新的 access token（可通过 response body 或 Set-Cookie 返回新的 refresh token）。

2) 单点刷新（避免并发刷新）

• 客户端在发现 access token 过期（401）时，不直接并发调用刷新接口，而是： a. 检查是否已有正在进行的刷新请求；若有，等待其结果并重试原始请求。
  b. 若没有，发起刷新请求，刷新完成后通知等待者继续请求。
• 技术实现：Promise 队列 / mutex / single-flight 库都可以。

3) 网络与重试策略

• 网络错误时使用指数退避（exponential backoff），限定最大重试次数与总时长，避免无限重试导致资源浪费或重复登录。
• 对于短暂的网络抖动，先尝试本地重试；多次失败后显示明确提示并给出手动刷新/重新登录入口。

4) CSRF 与安全加固

• 采用 SameSite cookie 能防止大部分 CSRF。如果使用 Strict 影响第三方跳转，可根据业务选 Lax。
• 对需要 PUT/POST/DELETE 的接口加 CSRF token 或使用双重提交 Cookie 策略（服务端校验）以更严格防护。
• refresh token 使用旋转（rotate）策略：每次刷新返回新的 refresh token 并使旧 token 过期，防止被截获后重放。

5) 设备与会话管理

• 服务端维护会话列表，支持单设备登出或按需主动下线可疑设备。
• 对敏感操作（修改密码、提现等）二次验证或强制重新登录。

6) UX 与降级体验

• 在页面显式显示登录状态和最后一次刷新时间，后台静默刷新时避免影响用户操作。
• 刷新失败切换到受限模式（只读或功能降级），并给出清晰的“重新登录”引导，减少用户流失。
• 在登录弹窗或页面加入“记住设备/不再询问”选项时，明确告知风险并在后端记录设备可信度。

7) 日志、监控与告警

• 记录刷新失败率、401 比例、并发刷新冲突次数等指标。
• 对异常增长设置告警，例如突然大量 401/refresh 失败可能是密钥变更或攻击。

实战提示（容易忽略但关键）

• 刷新接口要幂等：多次请求不要产生冲突状态，方便重试和并发控制。
• 前端不把 refresh token 暴露在任何 JS 可访问位置，避免 XSS 导致长期会话泄露。
• 在 SSR（服务器渲染）场景，cookie 在服务端也能直接读取，注意同样遵循 cookie 安全配置。
• 第三方 oauth 或 iframe 静默刷新方案复杂且容易被拦截，优先用后端 cookie+refresh 的方案。

一条讲透（总结） 把“会话管理”拆成两块：短期可被频繁替换的 access token（在内存里）负责请求鉴权；长期凭证只放到服务器管控的 httpOnly cookie（refresh token），并用单点刷新与退路策略保证刷新不出纰漏。做到这三点，登录态就稳了：安全、不易丢、用户体验好。