javascript无法实现session挤出机制，因session是服务端概念，前端仅能配合后端监听踢出事件、清空凭证并跳转登录页；根治需后端用redis维护用户当前有效token，新登录时作废旧会话并通知前端。

JavaScript 本身无法直接实现 Session 的“挤出机制”，因为 Session 是服务端概念，浏览器端的 JavaScript 没有权限主动销毁服务端 Session 或干预其他设备的登录状态。真正的单用户多设备登录挤出（即新登录踢掉旧登录）必须由后端控制，前端 JavaScript 只负责配合：监听被踢事件、清空本地凭证、跳转提示等。

服务端需维护用户登录会话映射

要实现“一个账号只能一处在线”，服务端必须记录每个用户的当前有效 Session（或 Token），例如用 Redis 存储：

• key：user:userId
• value：当前有效的 session_id 或 access_token（带过期时间）
• 每次用户登录成功时，先删除旧 Session，再写入新的，并通知旧设备失效

登录时主动作废旧会话

用户在设备 A 登录后，又在设备 B 登录，服务端应：

Java JDK 25

Java JDK 25 来自 OpenJDK 官方归档，版本为 JDK 25，本条下载地址已指向官方 Windows x64 zip 安装包直链，适合调试旧项目或兼容旧版 Java 运行环境。

下载

• 查出该用户已有活跃会话（比如存于 Redis 中的 token）
• 将旧 token 标记为无效（如加入黑名单、删 Redis key、或更新 user:userId 的值为新 token）
• 返回新 token 给设备 B，并可选返回状态码（如 201 Created with kickout）或字段（"kicked": true）

前端监听并响应被踢事件

设备 A 的页面需要感知自己已被挤出，常见做法有：

• 所有接口响应统一拦截：若后端返回 401 + { code: "SESSION_EXPIRED" }，说明 Session 已被服务端主动作废
• 定期轮询 /check-status 接口（轻量），或使用 WebSocket/Server-Sent Events 主动推送“你已被踢出”消息
• 收到踢出信号后，清空 localStorage/sessionStorage 中的 token，重定向到登录页，并提示“已在其他设备登录”

Token 设计建议增强可控性

使用 JWT 或自定义 Token 时，避免纯无状态，可结合服务端状态校验：

• JWT payload 中携带 sessionVersion（如用户最后一次登录的版本号），服务端每次踢人就递增该值
• 每次请求验证 JWT 时，额外查 Redis 中 user:userId 的当前 version 是否匹配，不匹配则拒绝
• 这样既保留 Token 的轻量性，又能实现精准会话控制

不复杂但容易忽略：前端永远不能只靠 localStorage 里的 token 判断是否登录，必须以服务端响应为准；挤出不是前端“登出”，而是服务端主动使旧凭证失效 + 前端及时响应。

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南