这个问题的核心答案是需要而且强烈建议存表持久化存储。但这里有一个关键误区存表不是为了“校验”Token的真假那是JWT签名做的而是为了“状态管理”和“安全控制”。下面我分三个层次帮你理清逻辑并给出工业级的最佳实践方案1. 为什么必须存表存什么如果只把 Refresh Token 当做普通的 JWT 来验签那它和 Access Token 没有区别失去了“可撤销”的意义。存表主要是为了管理以下状态黑名单退出登录用户主动退出必须将对应的 Refresh Token 标记为失效否则 Token 在有效期内依然可用。绝对过期时间JWT 本身带的exp是相对时间。存表可以记录revoked_at撤销时间或expires_at方便后台定时清理过期数据。设备/IP 绑定安全风控存储签发时的device_id或ip当刷新请求来自不同设备时可以直接拒绝并强制重新登录。一次有效性Reuse Detection这是最关键的安全点。如果 Refresh Token 被黑客截获他和你同时发起刷新请求。通过存表第二次使用的那个 Token 会被标记为“已使用”系统能立刻发现并撤销该用户家族的所有 Token。2. 存表时校验流程是怎样的不建议直接查数据库比对 Token 字符串那太慢了正确做法是双轨制验签本地先用密钥验证 JWT 的签名和有效期是否合法防篡改。验状态查表验签通过后拿着 Token 里的jtiJWT ID唯一标识去查 Redis 或 DB。检查status是否为revoked已撤销。检查refresh_count是否超过阈值防暴力刷新。检查绑定的设备指纹是否匹配。3. 存 MySQL 还是 Redis性能与安全的取舍这里有一个常见的性能优化策略我强烈建议采用Redis 为主 DB 为辅的架构存储方案优点缺点适用场景只存 MySQL数据绝对可靠便于审计历史记录高并发下每次刷新都查 DBIO 压力大内部管理系统并发低只存 Redis性能极高天然支持 TTL 自动过期重启丢失数据导致已撤销的 Token 再次生效对可用性要求不高的场景Redis 异步落库推荐兼顾高性能和高可用。Redis 做热数据校验DB 做冷数据备份和审计架构稍复杂绝大多数生产环境4. 标准表结构设计极简版如果你用 MySQL不需要存整个 Token 长字符串那玩意太长了利用 JWT 的jti作为主键即可sqlCREATE TABLE refresh_tokens ( jti CHAR(36) PRIMARY KEY, -- JWT的唯一ID对应UUID user_id BIGINT NOT NULL, device_id VARCHAR(64), -- 设备指纹 refresh_count INT DEFAULT 0, -- 累计刷新次数防滥用 revoked BOOLEAN DEFAULT FALSE, -- 是否撤销 expires_at DATETIME(3) NOT NULL, -- 绝对过期时间创建索引便于清理 created_at DATETIME(3) DEFAULT CURRENT_TIMESTAMP(3), INDEX idx_user_device (user_id, device_id) -- 便于查询用户的所有活跃设备 );5. 高级安全实践必看如果你的系统对安全性要求较高如金融、电商建议执行Refresh Token 轮换Rotation每次调用/refresh接口时不复用旧的 Refresh Token而是生成一个新的 Refresh Token返回给客户端。在数据库中软删除标记 revoked旧的jti并插入新的jti。核心逻辑如果同一个jti被请求了两次说明新旧两个客户端在抢着刷新立即将该用户所有设备的 Refresh Token 全部作废强制全网重新登录。总结建议小型项目存 Redis 就够了利用EXPIRE设置过期时间校验时只查 Redis 是否存在且未标记为revoked。中大型项目必须存表DB。因为 Refresh Token 的有效期通常很长7天~30天需要保证服务重启后依然能识别已撤销的 Token并且需要审计日志。一句话结论存表不是为了验签那是密码学的事而是为了让你拥有“让Token提前失效”的绝对控制权。所以一定要存。如果你们项目并发量很高想知道具体的 Redis Key 设计比如是存 Hash 还是 String以及如何原子性地处理轮换我可以再展开说说需要吗