双Token机制是JWT生产环境的底线方案，必须隔离解析、绑定设备指纹存Redis、前端共享刷新Promise、HttpOnly Cookie管理并校验IssuedAt防重放。
双 Token（Access + Refresh）机制不是“可选优化”，而是 JWT 在生产环境必须采用的底线方案。单靠 time.Now().After(claims.ExpiresAt) 做前端刷新判断，必然引发并发重复刷新、令牌复用、状态不一致——这不是边界 case，是每次高并发登录/提交时都会触发的实际问题。
为什么不能共用同一个 JWT 解析函数和密钥
Access Token 和 Refresh Token 必须走完全隔离的解析路径：不同密钥、不同 Claims 结构、不同校验逻辑。共用 ParseToken 函数但不传 isRefresh 参数，会导致以下风险：
- 用
accessSecret去验 Refresh Token，可能意外通过（若密钥巧合相同），把长期凭证当短期用 - 用
jwt.MapClaims解析 Refresh Token，却漏掉jti或fingerprint字段校验，失去防重放能力 - Refresh Token 的
exp是 7 天，但解析时误套 Access Token 的 15 分钟逻辑，提前拒绝合法刷新
实操上，应定义两个独立函数：ParseAccessToken() 只校验 exp 和 iss；ParseRefreshToken() 必须显式检查 claims.VerifyExpiresAt(now, true) 并返回 user_id 和 jti，且只接受 refreshSecret。
Refresh Token 必须绑定设备指纹并存入 Redis
JWT 标准不支持吊销，所以 Refresh Token 不能纯无状态。不绑定、不落库，等于默认允许无限续期。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- Redis Key 格式建议为
refresh:{user_id}:{fingerprint_hash}，其中fingerprint_hash由sha256(fmt.Sprintf("%s:%s", r.UserAgent(), realIP))生成 - 签发时用
SETEX写入，TTL 设为固定值（如 7 天），而非滑动过期——滑动会延长泄露 Token 的危害窗口 - 刷新接口收到请求后，第一步不是解析 JWT，而是
DEL refresh:{user_id}:{fingerprint_hash}；成功生成新对后再写入新 Key - 若 DEL 返回 0，说明该设备指纹已被登出或换绑，直接拒绝，不解析 Token
前端拦截器必须共享 Promise，不能各自发请求
多个并发请求同时收到 401，若每个都调 /auth/refresh，服务端就会收到 N 个刷新请求——而 Redis 的 DEL 是原子的，只有一个能成功，其余全失败，前端则陷入“刷新失败 → 清登录态 → 用户正在填的表单丢失”循环。
- 全局维护一个
let refreshPromise: Promise<string> | null = null - 首次 401 触发
refreshPromise = fetch(...).then(...)，后续所有 401 都await refreshPromise - 刷新成功后，用新
accessToken重放原始请求；失败则refreshPromise = null并跳登录页 - 别在拦截器里读
localStorage取 refreshToken——HttpOnly Cookie 才安全，前端 JS 本就不该接触它
刷新接口必须清旧 Cookie 并拒绝复用旧 jti
如果用 HttpOnly Cookie 存 Refresh Token，刷新成功却不清理旧值，浏览器下次请求仍会自动带上已失效的 Token，导致 401 → 刷新 → 401 死循环。
- 响应中必须调两次
c.SetCookie()：一次清旧（maxAge = -1），一次设新（maxAge = 7*24*3600） - Redis 中以
jti为 Key 存储状态，不是user_id—— 同一用户多设备登录时，必须能单独作废某一台的 Refresh Token - 刷新成功后，新 Refresh Token 的
jti必须是服务端新生成的 UUID，禁止客户端传、禁止时间戳拼接 - 别在刷新逻辑里查用户表——
sub和jti必须足以完成全部校验，否则引入竞态（如用户刚登出，刷新请求却查到“有效用户”）
最易被忽略的一点：Refresh Token 的 exp 是硬边界，但它的“可用窗口”还受服务端策略约束——比如允许从签发起最多刷新 7 天，这个 7 天不能只靠 JWT 的 exp 控制，而要在解析后比对 claims.IssuedAt 和当前时间，否则攻击者可重放旧 Token 绕过限制。
