不能靠 Redis Pub/Sub 做「踢人」的主逻辑，它仅能辅助通知；真正踢人必须依赖 FindByIndexNameSessionRepository 主动销毁 session，否则会出现漏踢、延迟踢或未踢。
直接说结论：不能靠 Redis Pub/Sub 做「踢人」的主逻辑，它只能辅助通知，真正踢人必须依赖 FindByIndexNameSessionRepository 主动销毁 session，否则会出现漏踢、延迟踢、甚至根本没踢的情况。
为什么 Pub/Sub 不能单独承担踢人职责
Redis 的 Pub/Sub 是“发了就不管”的广播机制，不保证送达、不持久、无重试、无 ACK。Spring Session 虽然会向 session:deleted、session:expired 等 channel 发布事件，但这些事件只在 session 实际被删除/过期时才触发——而「踢人」是主动提前删 session，此时 Pub/Sub 根本不会收到任何消息。
常见错误现象：
- 管理员调用踢人接口后，用户仍能继续访问 1–2 分钟
- 某台服务节点没监听到 Pub/Sub 消息，该节点上的 session 一直存活
- 网络抖动或 listener 启动晚于 session 创建，导致消息丢失
FindByIndexNameSessionRepository 是踢人的唯一可靠入口
Spring Session 的 RedisIndexedSessionRepository 实现了 FindByIndexNameSessionRepository 接口，提供 findByIndexNameAndIndexValue 方法，能精准查出某用户（PRINCIPAL_NAME_INDEX_NAME）的所有活跃 session ID。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
实操建议：
- 注入时必须加
@Lazy，否则可能触发循环依赖：@Lazy private FindByIndexNameSessionRepository extends Session> sessionRepository; - 查 session 用固定索引名：
sessionRepository.findByIndexNameAndIndexValue(FindByIndexNameSessionRepository.PRINCIPAL_NAME_INDEX_NAME, username) - 逐个调用
sessionRepository.deleteById(sessionId)—— 这才是真实销毁，会同步清理 Redis key 并触发SESSION_DELETED事件 - 不要用
redisTemplate.delete()直接删 key，绕过 sessionRepository 会导致 Spring Session 内部状态不一致
Pub/Sub 只适合做「被动清理」和「跨节点通知」
它的合理用途是：当某个节点主动删 session 后，其他节点通过监听 session:deleted 事件，清掉本地线程缓存（如 SecurityContext）、关闭 WebSocket 连接、更新在线状态 UI 等。
配置要点：
- 监听器必须注册到
RedisMessageListenerContainer，且明确订阅sessionRepository.getSessionDeletedChannel() - channel 名由
RedisIndexedSessionRepository动态生成，别硬编码成spring:session:events:session:deleted—— 不同命名空间下 channel 名不同 - 监听到事件后，仅做轻量操作：比如调用
SecurityContextHolder.getContext().setAuthentication(null)，别再反向查 session 或删 Redis key
最易被忽略的一点：踢人动作必须发生在「业务层」而非「安全过滤器链内」。比如管理员调用 /api/user/kick/{userId} 接口时执行销毁逻辑，而不是等用户下次请求经过 Filter 才判断——后者已晚了，请求早已进入业务方法。真正有效的踢人，是让 session 在被删那一刻就失效，不是等下一次校验。
