运营后台点了封禁，用户 App 里还能接着下单，JWT 为什么踢不掉？

结论先说在前面：如果需求里明确写着封号、踢下线、改密后其他端退出要立即生效，优先选服务端可撤销的登录态（典型是 Session 或服务端会话表）；如果同时要服务 App、小程序和开放接口，且能接受秒级到分钟级的撤回延迟，再用 JWT 加一层用户级版本号或 jti 黑名单。两种方案都能多端登录，差别不在性能，而在撤掉一个登录态需要动谁。

先看撤回能力：删记录和等过期是两回事

Session 由服务端保存会话记录，浏览器只拿一个不可猜测的会话 ID，每次请求回查记录，判断你是谁、有没有过期、有没有被踢。JWT 把用户标识和有效期签进 Token，服务端验签即可，不用落库查询，这也是它在跨服务调用里顺手的原因。

代价是 JWT 签发后没法直接撤回。封号、异地登录踢下线、改密清其他端，这类需求会直接决定方案。JWT 要做等效效果，通常要补用户级版本号或 jti 黑名单，每个受保护接口多查一次缓存。2026 年常见做法是在网关统一校验，避免每个服务各写一遍。

• Session 的成本：需要共享存储（常见是 Redis）让多实例共享会话，存储不可用时登录态会整体失效。
• JWT 的成本：服务端无状态、扩容方便，但注销、踢下线、权限即时变更都要额外实现。
• 共同的成本：都要处理令牌被窃取后的窗口期，区别只是窗口长短和补救手段。

按四个条件核对，撤回时效排在第一位

1. 部署形态与实例数：单实例或少量实例、已有共享缓存，Session 落地成本低；实例频繁扩缩，JWT 更顺。
2. 端与域：只有同域网页，Cookie + Session 结构简单；同时要服务 App、小程序、第三方开放接口，Token 少踩 Cookie 域和 SameSite 的坑。
3. 撤回时效：要求立即生效的场景，Session 天然满足；JWT 需要补机制，常见经验区间是多出 1~3 天开发与联调量，端数越多越靠近上限。
4. 运维与排查：Session 依赖共享存储，多一层可用性要求；JWT 好扩容，但排查请求身份更依赖日志里的 jti 或用户 ID。

第三项若写成必须立即生效，第四项的扩容便利通常要让位；反过来，如果第二项同时有 App、小程序和开放接口，Cookie 方案的适配成本往往超过给 JWT 补一层黑名单。四项核对完，候选通常只剩一两个。

决定用 JWT 后，Token 放哪、怎么续才容易出问题

Token 放 localStorage 会被 XSS 直接读走，放普通 Cookie 又引入 CSRF，除非同时配好 SameSite 与 CSRF 校验。按 2026 年常见交付做法，比较稳的组合是短效 Access Token 加长效 Refresh Token：Access Token 只放内存，Refresh Token 放 httpOnly + Secure + SameSite 的 Cookie，由服务端签发并支持吊销。

Access Token 有效期常见区间是 15 分钟到 2 小时，Refresh Token 是 7 到 30 天（均为经验区间，按业务敏感度调整）。设短了刷新频率高，前端并发请求容易同时触发多次刷新，需要在客户端做单飞；设长了，令牌泄露后的可利用窗口变长，撤回能力更依赖服务端黑名单。

• 方案 A：Session + 共享存储：撤回直接，删记录即失效；跨端适配成本较高；多一层存储可用性要求；适合同域后台、单体或少数服务。
• 方案 B：JWT + Refresh Token：跨端与网关统一验签成本低，服务无状态易水平扩展；撤回需额外机制；适合多端在线、服务拆分、对外开放接口。

交付现场：封号需求往往比预想来得早

常见情况是预算和周期都紧，需求文档只写了手机号密码登录，开发直接签一个有效期很长的 Token，Refresh 机制和注销接口都没做。上线两三周后运营提了封禁账号，才发现封了账号原 Token 依然能用，只能临时加一张用户级版本号表，在所有受保护接口上多校验一次，并把已有登录态全部强制失效、让用户重新登录。这类返工的触发点常见区间是上线后 1~4 周，代价是一次全员重登加一轮回归测试。

要避免它，其实只要在选型阶段多问一句：三个月内会不会出现踢人、封号、改权限的需求？把答案写进方案说明，再决定是纯 JWT 还是 JWT 加版本号。交付时先核对登录态相关的验收项，比上线后补救省事。

适用与不适用边界

适合 JWT 的情况比较明确：同一账号要在 App、小程序、网页多端在线，服务已拆分或要经网关统一鉴权，需要向第三方开放接口，或者希望服务无状态以便随时扩缩容。适合 Session 的情况同样明确：同域后台系统、单体或少数几个服务、对立即踢下线有硬要求、团队运维力量有限，且已有共享缓存可用。

边界也要写清楚：如果只是内部工具、用户量在几十到几百、没有多端也没有开放接口，两种方案的差别很小，直接选团队更熟悉的那套即可，不必为登录态单独引入 Redis 集群或黑名单服务；反过来，如果业务要求权限变更近乎秒级生效、且服务数量很多，纯 JWT 的撤回短板会变成长期维护负担，这时更稳妥的做法是在网关统一鉴权并保留服务端会话状态。

常见问题

JWT 一定比 Session 性能好吗？

单次请求的差别通常很小，JWT 省掉的主要是一次会话查询，真正的瓶颈一般落在数据库和网络上。用户量不大时，性能不该作为选型理由。

用了 JWT 还能实现踢下线吗？

可以，但需要额外机制。常见做法是给用户维护 Token 版本号或 jti 黑名单，校验时比对，代价是每个受保护接口多一次缓存查询。

前后端分离，Session 就必须换成 JWT 吗？

不必。前后端分离和登录态方案是两件事，只要处理好跨域携带 Cookie，再配 SameSite 与 CSRF 校验，Session 一样能跑。

多端登录要限制几个设备在线，怎么定？

常见区间是 1~5 个端。超出时踢掉先登录的那一个，并把设备标识记在会话记录或版本表里，避免只处理当前端而不处理其他端。

下一步可以先写一页结论：把部署形态、端数、撤回时效、运维成本各写一句，再决定方案。若选 JWT，务必同时定好 Refresh 机制、注销与踢下线路径，并写进交付验收清单。若撤回要求还没定，先用 Session 上线并把登录态封装到一处，后续替换的改动面会更可控。