JWT黑名单与会话机制有何区别？引入黑名单后是否与会话逻辑一致？

你的核心理解没有错误：引入中心化黑名单校验后，JWT原本的无状态优势确实会被部分抵消，两者的请求校验链路从流程上看高度相似，但实际落地时的成本和扩展性仍有明显区别，具体差异如下：

• 查询成本差距确实存在，黑名单查询远快于全量会话拉取
  黑名单仅存储「有效期内被主动吊销的令牌」，正常过期的令牌会自动从黑名单中清理，多数业务场景下主动吊销的令牌占活跃会话的比例不足5%，存储量级远小于全量会话缓存。且黑名单仅需要做exists 令牌ID的存在性判断，不需要拉取用户权限、会话属性等完整会话数据，Redis场景下这类查询的耗时通常在1ms以内，比拉取完整会话数据的耗时低30%以上。
  你还可以对黑名单做应用节点本地缓存（比如缓存10s的黑名单数据），由于JWT本身自带有效期，即使短暂未同步最新黑名单，最坏情况也只是被吊销的令牌多生效10s，业务风险可控，这种场景下甚至不需要每次请求都访问中心化缓存，性能优势会进一步拉大。
• 两者的扩展性差异主要体现在多服务架构场景
  传统会话令牌本身不携带任何业务信息，所有服务每次请求都必须从中心化缓存拉取完整会话数据才能完成权限校验；而JWT本身已经内置了用户ID、角色权限、业务上下文等所需信息，只要确认令牌不在黑名单中，直接解析本地就能拿到所有校验需要的信息，不需要额外调用其他接口或访问缓存，跨服务场景下的整体链路耗时反而更低。
• JWT黑名单方案的灵活度远高于传统会话
  你可以根据接口安全等级灵活配置校验逻辑：比如支付、改密等高敏感接口才校验黑名单，普通查询类接口仅校验JWT签名合法性即可，不需要每次都查缓存；如果缓存集群出现故障，JWT方案还可以降级为暂时跳过黑名单校验，只要签名合法就放行，保障核心业务可用，这是传统会话方案无法做到的。

内容的提问来源于stack exchange，提问作者bldcaveman