不能直接用http.SetCookie存储长期Token，因泄露后攻击者可无限期冒充用户；Token Rotation要求每次使用后立即作废旧Token并签发新Token，需服务端维护状态（如Redis中存哈希值、revoked标记），而非仅依赖JWT的exp字段。
为什么不能直接用 http.SetCookie 存储长期有效的 Token
因为会话 Token 一旦泄露，攻击者就能无限期冒充用户。Token Rotation 的核心逻辑是：每次成功使用（如刷新、访问受保护资源）后，立即作废旧 Token，并签发一个新 Token。这要求服务端必须维护 Token 的有效性状态，不能只依赖 JWT 自带的过期时间（exp）——否则无法实现“单次使用即失效”。
常见错误是把 Token 当成无状态凭证直接存进 Cookie，然后靠 exp 控制生命周期，结果导致中间人截获后仍可重放数分钟甚至数小时。
- 必须在服务端存储 Token 的哈希值（而非明文），配合
used_at或revoked字段标记是否已被消耗 - 数据库或 Redis 中每条记录应包含：
token_hash、user_id、expires_at、revoked（布尔）、created_at - JWT 签发时仍需设较短的
exp（如 15 分钟），但实际有效期由服务端状态决定
如何用 gorilla/sessions 配合自定义 Token Store 实现 Rotation
gorilla/sessions 本身不处理 Token Rotation，但它能安全地管理会话 Cookie 的加密传输和签名验证。关键在于把 Token 的生命周期控制逻辑从 Cookie 层剥离，交由独立的 Token Store 处理。
典型流程是：用户登录后，生成一对 Token（access_token + refresh_token），两者都存入 Token Store；后续请求携带 access_token，校验通过后立即 revoke 它，并签发新的 access_token 返回给客户端。
- 不要把
refresh_token放在 Cookie 里自动发送——它应只在显式调用/auth/refresh时由前端主动提交（且建议用HttpOnly=false+SameSite=Lax） - 每次签发新
access_token时，必须调用 Token Store 的Revoke(tokenHash)方法，再调用CreateNew(user, expires) - Cookie 的
MaxAge应设为 0（会话级），避免 Token 过期后还滞留在客户端磁盘
Redis 中存储 Token 的结构设计与 TTL 注意点
用 Redis 实现 Token Store 最常见，但容易忽略两个关键点：一是哈希碰撞防护，二是 TTL 与业务逻辑的错位。
推荐结构：token:{sha256(token_plaintext)} → JSON 字符串（含 user_id, expires_at, revoked）；同时用 zset 按 expires_at 做过期扫描（非必需，仅用于清理）。
- 必须对原始 Token 做
sha256再存，禁止明文存储——否则 Redis 被入侵等于全量 Token 泄露 - 设置 Redis key 的
EXPIRE时间要略长于 Token 的逻辑过期时间（比如 Token 逻辑 15 分钟过期，Redis TTL 设 20 分钟），防止因系统时钟误差或网络延迟导致提前被删 - 在
ValidateToken函数中，先查 Redis，再检查revoked == false && time.Now().Before(expires_at)，二者缺一不可
前端如何配合 Token Rotation 避免 401 闪退
前端不是被动接收新 Token 就完事了。如果多个并发请求携带同一个旧 Token，其中第一个请求成功换新，其余请求就会因 Token 已被 revoked 而失败，造成 UX 断裂。
解决方案是加一层 Token 请求队列 + 状态缓存。例如用一个 sync.Map（Go 后端）或 Promise 缓存（前端）暂存正在刷新中的 Token 请求。
- 前端发起请求前，先检查当前
access_token是否临近过期（比如剩余 /auth/refresh - 所有请求拦截器统一读取一个共享的
currentAccessToken变量，该变量只在刷新成功后原子更新 - 遇到 401 且响应体含
{"error":"token_revoked"}，说明发生了竞争，此时应丢弃所有 pending 请求，强制重试（或跳转登录）
