应引入 JWT Refresh Token 机制：后端登录时返回短时效 Access Token 和长时效 Refresh Token，后者存数据库/Redis 并严格校验；前端拦截 401 后用 HttpOnly Cookie 刷新，实现无感续期。

接口返回 401 并提示 Token 过期，说明当前 Access Token 已失效。这不是前端该“重试几次”或“手动清缓存”就能解决的问题，而是需要后端配合、前后端协同的认证机制升级——核心解法就是引入 JWT Refresh Token。

为什么单靠 Access Token 行不通

Access Token 设太短（如 15 分钟），用户操作中频繁掉登录；设太长（如 7 天），一旦泄露，攻击者可长期冒用。这不是参数调优问题，而是架构缺陷。Refresh Token 的存在，就是为了把“安全”和“体验”拆开管理：

• Access Token 只管业务请求，有效期控制在 15–30 分钟，泄露危害小
• Refresh Token 只管换新 Access Token，有效期设为 7–30 天，但本身不能调用任何业务接口
• 两者职责分离，互不越界

后端必须做的三件事

仅前端改拦截器没用，后端是刷新机制的基石。关键动作包括：

TokenGX Cap 验证码集成

TokenGX Cap 验证码【代码集成】技能 —— 面向开发场景，提供前端组件和后端验证的代码模板，帮助用户将 Cap 无感验证码快速集成到网站或应用中。适用场景：注册登录防刷、表单提交保护、API 接口防爬、发短信/邮件防滥用等。支持前端（HTML/React/Vue/Next.js）和后端（Node.js/Python/PHP/Go）全栈集成。触发词：集成验证码、添加人机验证、CAPTCHA 集成、cap widget、验证码前端、验证码后端、防刷表单等。与 tokengx-cap-admin（服务

下载

• 登录时返回两个 Token：生成短时效 Access Token（含 exp）+ 长时效 Refresh Token（推荐用随机 UUID，非 JWT）
• Refresh Token 必须持久化：存数据库或 Redis，字段至少含 token 值、user_id、expiry_date、is_revoked。不能只存在内存里，否则无法吊销
• /refreshtoken 接口需严格校验：查库确认 Refresh Token 存在、未过期、未被标记为已使用（防重放），通过后再签发新 Access Token，并可选更新/作废旧 Refresh Token（滚动刷新）

前端无感刷新的关键实现

用户不该感知 Token 刷新过程。前端需借助请求拦截器（如 axios.interceptors）完成闭环：

• 响应拦截器捕获 401 状态码且错误信息指向 token 过期
• 触发刷新流程前，将后续所有待发请求暂存队列（避免并发多次刷新）
• 用 HttpOnly Cookie 自动携带 Refresh Token 请求 /refreshtoken 接口（不从 localStorage 读，防 XSS）
• 拿到新 Access Token 后，更新本地存储（如内存变量），再逐个重放暂存请求

安全加固不可少的细节

Refresh Token 不是万能钥匙，用错反而放大风险：

• Refresh Token 严禁存 localStorage 或 sessionStorage
• 必须通过 Set-Cookie 返回，带 HttpOnly、Secure、SameSite=Strict 参数
• 每次成功刷新后，应立即让旧 Refresh Token 失效（数据库 UPDATE is_used = 1 或 Redis DEL）
• 支持主动登出或改密时批量清除用户所有 Refresh Token