搜这几个词的人通常卡在同一个动作上：登录接口返回了一串字符，不知道该把它当 JWT 还是当 Session id，于是没法判断“登出后旧凭证还能不能用”“多实例部署要不要加 Redis”。先把判断落在两个可核对的现象上——登录响应里凭证的形状，以及服务端有没有一份能被删除的会话记录；再看你用的框架（Sa-Token）默认把凭证放在哪一层。这三件事确认完，选型才谈得上。
抓一次登录响应：短随机串加 Set-Cookie，且服务端能立刻删掉这条会话，属于 Session 形态，Sa-Token 默认走这条路；三段式、能本地解出 payload、登出后旧凭证仍可用到过期，属于 JWT。选哪边取决于是否需要即时踢人和多实例共享，而不取决于哪个更先进。把有效期、撤销能力和存储依赖一起看。
JWT和Session的区别是什么
这一步对应的是“认证结果放在哪里”的判断：JWT 把身份信息签进凭证本身，服务端不存；Session 只发一个标识，身份数据留在服务端内存或 Redis。确认方法不需要读源码，直接在本地发一次登录请求观察即可。
curl -i -s -X POST 'http://localhost:8080/api/login' \
-H 'Content-Type: application/json' \
-d '{"username":"demo","password":"demo"}' \
| grep -i -E 'set-cookie|authorization|token'把返回的凭证取出来，三步核对：
- 数一数有没有两个英文句点。三段式且中段能用 base64 解开并包含 exp、sub 之类字段，是 JWT；固定长度的随机串更可能是 Session id 或 Sa-Token 生成的 token 值。
- 调用一次登出接口，再用旧凭证重放一个需要登录的接口。返回 401 说明服务端能立刻撤销；仍然返回 200 且要等到过期才失效，说明凭证是自包含的。
- 查服务端有没有会话记录。Sa-Token 集成 Redis 时通常会看到前缀相关的键，可以先扫一遍：
redis-cli --scan --pattern '*satoken*'；用内存存储时则在应用进程里，重启即清空——这也是一个很好用的判别信号。
常见坑：看到“token”这个词就默认是 JWT。Sa-Token 默认发的是一串随机字符加服务端会话记录，本身不带签名和 payload，除非你显式接入它提供的 JWT 相关插件或自行签发，否则它不是 JWT。风险边界在于：靠字符串长度、靠字段名都不稳，只认“能不能本地解开 + 服务端能不能撤销”这两个现象。
请简述cookie token Session和JWT四种身份机制的区别
这四者其实不在同一层：Cookie 是浏览器端的传输载体，Token 是凭证的统称，Session 和 JWT 是两种不同的状态管理做法。核对位置可以按层找。
- Cookie：看浏览器开发者工具的“应用/存储 → Cookie”，或响应头里有没有
Set-Cookie。有 HttpOnly、Secure 标记说明它是被刻意保护起来的传输层。 - Token：看响应体或
Authorization请求头里那个字符串，它只是载体形式，不说明后端怎么存。 - Session：看服务端存储，Redis 里的会话键或框架的在线会话列表；Sa-Token 可以在会话治理相关页面或接口里看到同一账号的登录列表。
- JWT：把中段单独取出来本地解码，不要上传到任何在线工具，避免泄露：
echo '<把payload段粘在这里>' | tr '_-' '/+' | base64 -d 2>/dev/null能解出可读 JSON，就是自包含凭证；解不出来、只有一个随机串，就是标识类凭证。这四种机制的差别，最终都落回一句话：身份数据在客户端还是在服务端。
JWT和Session：各自站在什么位置
JWT 站在“凭证格式”的位置：它擅长把少量声明签好名交给调用方，任何持有公钥或密钥的服务都能独立校验，不需要回查中心存储，适合跨服务、跨语言、短时有效的场景。代价是签发出去之后无法单条撤回，只能等过期或额外维护黑名单。
Session 站在“状态管理”的位置：它擅长需要随时掌握“谁还在线、能不能立刻踢掉、权限改了什么时候生效”的场景，服务端说了算。代价是每次校验要读一次存储，多实例部署必须共享存储。
Sa-Token 站在框架的位置，把发凭证、存会话、校验、踢人、续期这几步包起来，会话可以放内存也可以放 Redis，并额外提供 JWT 风格的集成方式。判断口径：JWT 侧查 RFC 7519 里的 iss、exp、sub 等标准声明，看你签出来的载荷是否只放了这些；Sa-Token 侧查它官方文档中“会话存储 / 集成 Redis / JWT 插件”相关章节和配置项名称（例如会话超时、是否允许同账号并发登录这类参数），不同大版本目录名和参数名可能不同，以你本地引入的依赖版本为准，先把版本号写在笔记里再对照。
JWT和Session：性能、成本、运维、上手四个口径分开比
性能：差别主要在每次请求是否多一次存储读取。量法是自己压测：用同一台机器对同一个受保护接口跑 wrk 或 JMeter，Session 形态分别测内存存储和 Redis 存储两组，Redis 侧同时看 redis-cli --latency 和 INFO stats 里的命中情况。别人给的数字没有参考价值，因为取决于网络和序列化方式。
成本：Session 形态多一份集中存储，成本看 Redis 实例规格和 INFO memory 里的实际占用，再对照云厂商计价页面上该规格的价格；JWT 形态省掉存储，但如果要做撤销名单，等于又把这份成本部分加回来。把两边的月度账单项列出来比，比口头说“省”更靠谱。
运维：Session 形态要求存储高可用，Redis 挂了登录态就受影响，需要配主从或集群，并在应用侧设置合理的超时；JWT 形态要求密钥或公私钥的分发与轮换有流程，密钥泄露的影响面比单个会话大。两边都要在监控面板上盯一个指标：登录失败率和 401 比例。
上手：Sa-Token 这类框架通常引入依赖、写几行配置、调用登录方法就能跑通，适合已有 Java 项目；纯 JWT 方案要自己写签发、校验过滤器、过期与刷新逻辑，代码量更大但依赖更少。判断标准是你团队更愿意维护配置还是维护代码。
JWT和Session：什么情况选哪一边
单体应用或实例数有限、需要即时踢人和权限立即生效：选 Session 形态，用 Sa-Token 默认方式并把会话放到 Redis。前置条件是团队接受该框架、Redis 有可用的高可用方案、能接受每请求一次存储读取；验证方式是改一次用户权限后立刻请求受保护接口，确认新权限生效、旧会话被踢后返回 401。
多服务、跨语言调用或需要边缘校验：选 JWT，把有效期设短，配合刷新机制。前置条件是能接受“过期前无法单条撤销”，并且载荷里只放用户标识和少量声明，不放手机号、角色明细等敏感或易变数据；验证方式是拿旧令牌在登出后重放，确认在有效期内仍然通过——这是已知边界，不是 bug，要提前和业务方讲清楚。
已有 Spring 项目想少写代码但又要撤销能力：用 Sa-Token 管会话、需要给外部系统发凭证时再单独签 JWT，两种凭证各自负责各自的调用方。前置条件是两套凭证的鉴权入口在网关或过滤器里区分清楚，避免同一个接口接受两种凭证却用不同的失效规则；验证方式是分别用两种凭证访问同一接口，确认权限判断和失效行为一致。