JWT迁移核心是将用户状态从服务端转至客户端Token，前端改用localStorage存Token并带Bearer头请求，后端改验签名与时间戳，需引入Refresh Token机制处理过期，并强化HTTPS、敏感操作二次验证及黑名单等安全措施。
将传统 Session 认证迁移到 JWT，核心是把服务端“记住用户”的责任，从服务器内存或数据库（Session 存储）转移到客户端 Token 本身，并通过签名保证不可篡改。
1. 前端登录流程要改：用 JWT 替代 Cookie 写入
原来登录成功后，后端 set-cookie 写入 Session ID；现在登录成功后，后端返回一个 JWT 字符串（如 eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9... ），前端需主动存起来——推荐用 localStorage 或 sessionStorage（注意 XSS 风险），不再依赖浏览器自动携带 Cookie。
- 后续每次请求（尤其是受保护接口），在
Authorization请求头中带上：Bearer <your-jwt-token> - 前端路由守卫（如 Vue Router 的
beforeEach、React 的自定义 Hook）需检查本地是否有有效 Token，没 token 或过期则跳转登录页 - 避免把敏感信息（如密码、权限列表）直接塞进 JWT payload，只放必要标识（如
userId、role），权限校验仍应在后端做
2. 后端验证逻辑要重写：不查 Session，只验 Token
原来中间件（如 Express 的 session()）会根据 Cookie 中的 Session ID 查 Redis 或数据库；现在要换成 JWT 验证中间件：
- 从
Authorization头提取 Token，用相同密钥（secret 或公私钥）验证签名是否有效 - 检查
exp（过期时间）、nbf（生效时间）等标准字段，拒绝过期或未生效 Token - 验证通过后，把 payload 中的用户信息（如
userId）挂到req.user上，供后续业务逻辑使用 - 不再调用
req.session.destroy()，登出只需前端清除本地 Token 即可（严格来说，JWT 本身无法“主动失效”，需配合黑名单或短生命周期 + 刷新机制）
3. 处理 Token 过期与刷新：不能只靠延长 exp
JWT 一旦签发就不可更改，所以不能像 Session 那样“续期”。常见做法是引入 Refresh Token：
立即学习“Java免费学习笔记（深入）”；
- 登录时，后端同时下发 Access Token（短时效，如 15 分钟）和 Refresh Token（长时效，如 7 天），后者通常存于
httpOnlyCookie 或安全存储中 - Access Token 过期时，前端用 Refresh Token 向
/refresh接口换新 Access Token，后端验证 Refresh Token 合法性并生成新 Token - Refresh Token 应绑定设备/指纹，且每次使用后作废（或滚动更新），防止被盗用
4. 安全细节不能省：JWT 不是银弹
JWT 简化了状态管理，但带来新风险，必须补足：
- Token 必须通过 HTTPS 传输，禁止明文 HTTP
- 敏感操作（如改密码、支付）仍需二次验证（如短信/邮箱确认），不能仅凭 JWT
- 避免在 JWT 中存放过多用户数据，payload 超大影响传输效率，也增加泄露风险
- 服务端要实现 Token 黑名单（如 Redis 存已注销的 jti），用于强制登出或密码修改后使旧 Token 失效
