双令牌机制是唯一稳妥路径，因单靠time.now().after(claims.expiresat)判断会引发并发刷新冲突、令牌复用及状态失控；refreshtoken必须绑定设备指纹、存入redis并强制jti轮换，前端需共享promise排队刷新。
Go 语言里实现 JWT 刷新令牌，核心不是“能不能做”，而是“怎么避免并发刷新冲突、令牌被复用、服务端状态失控”。双令牌（accessToken + refreshToken）是唯一稳妥路径，单靠前端计时器或后端无状态校验必然出问题。
为什么不能只靠 time.Now().After(claims.ExpiresAt) 做刷新判断
JWT 的 exp 字段只是签名内的时间戳，它不等于“当前请求是否该被拒绝”——中间件校验失败返回 401 是服务端行为，而前端拿到 401 时，可能已有多个并发请求正在等待响应。此时若每个请求都独立发起 /auth/refresh，就会触发多次刷新，导致：
- 服务端生成多对新令牌，旧
refreshToken可能未及时失效，被重复使用 - 前端收到多个新
accessToken，但无法确定哪个是最终有效版本，覆盖逻辑混乱 - 用户在表单提交中途被刷新覆盖，
Authorizationheader 突然变更，后端校验失败
refreshToken 必须绑定设备指纹 + 存入 Redis 做状态管理
JWT 标准本身不支持吊销，所以 refreshToken 不能纯无状态。你在 Go 中生成它时，Payload 至少要包含：
-
user_id：用于关联用户 -
fingerprint：由客户端 UA + IP（或更稳的 device_id）哈希得出，如sha256(fmt.Sprintf("%s:%s", r.UserAgent(), realIP)) -
jti：唯一 ID，每次刷新必须更新，且服务端需记录其是否已被使用
验证 refreshToken 时，Go 后端必须：
- 先用
jwt.Parse解析并校验签名和exp - 查 Redis：
GET refresh_token:{jti}，确认存在且值为user_id:fingerprint - 查完立刻
DEL refresh_token:{jti}（单次使用），再生成新对并写入新jti
不这样做，攻击者截获一个 refreshToken 就能无限续期。
前端请求拦截器里别写“自动重试”，要写“排队+共享 Promise”
在 Go 项目配套的前端（比如 Vue 或 React）中，错误处理层不能对每个 401 都直接调 /auth/refresh。正确做法是用一个全局 refreshPromise 缓存正在执行的刷新请求：
- 首次遇到
401，触发刷新，把 Promise 存进变量 - 后续所有同时间的
401请求，都await这个 Promise，而不是各自发请求 - 刷新成功后，用新
accessToken重放原始请求；失败则清空登录态
否则你看到的现象是：点提交按钮瞬间弹出 3 个登录框，或者表单提交返回 401 后又立刻 403 ——因为令牌已轮换但请求没重放。
Go 服务端刷新接口必须返回新 refreshToken，且禁止复用旧值
很多团队为了“省事”，刷新接口只返回新 accessToken，refreshToken 不变。这在生产环境是严重漏洞：
- 旧
refreshToken仍有效，等同于长期凭证未轮换 - 无法实现“踢出其他设备”功能（因为没新
jti可标记） - Redis 中旧
jti未删除，新请求仍可能命中缓存
正确响应结构应为：
{
"access_token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...",
"refresh_token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...",
"expires_in": 900
}
对应 Go 处理逻辑中，必须调用一次 generateRefreshToken()，生成新 jti，写入 Redis，并确保旧 jti 已被 DEL。
最容易被忽略的是：刷新不是“换一张新通行证”，而是“注销旧钥匙、发放新钥匙、并登记新锁芯编号”。任何跳过状态同步（Redis）、跳过指纹绑定、跳过 jti 轮换的实现，都会让安全模型形同虚设。
