核心思路是让旧Session失去验证资格，而非仅清除存储数据；需在Session中绑定密码版本号或哈希，每次请求校验时比对用户当前凭证状态，改密时更新版本并清理旧会话。
用户修改密码后，要让其他活跃会话（比如在另一台设备或浏览器上登录的 Session）立即失效，核心思路是：**让旧 Session 失去验证资格，而不是单纯清除服务端存储的 Session 数据**。JavaScript 本身（前端）无法直接操作 Session 的生命周期，真正起作用的是后端逻辑配合合理的 Session 管理策略。
关键：Session 绑定用户凭证状态
默认情况下，Session ID 只关联一个用户 ID，不感知密码是否变更。要实现“改密即踢出其他会话”，需在验证 Session 时额外检查该 Session 创建时对应的密码哈希（或版本标识）是否仍有效。
- 用户登录成功后，服务端生成 Session，并把 当前密码的哈希值（或密码更新时间戳、版本号）一并存入 Session 数据（如 Redis 中的 session:abc123 → {userId: 100, pwdHash: "sha256:xxx", createdAt: 171...}）
- 每次请求校验 Session 时，不只是查 userId，还要比对存储的 pwdHash 是否与数据库中该用户当前的 pwdHash 一致
- 用户修改密码后，服务端清空该用户所有旧 Session 的 pwdHash 字段，或直接删除其全部 Session 记录
推荐做法：用 Token 或 Session 版本号代替密码哈希
直接存密码哈希存在安全顾虑（虽不直接暴露明文），更稳妥的方式是引入一个轻量级、可高频更新的凭证字段：
- 为每个用户维护一个 sessionVersion 字段（例如数据库 users 表加一列，初始为 0）
- 登录成功时，Session 中记录
userId + sessionVersion（如 {uid: 100, ver: 5}） - 每次验证请求前，先查数据库确认当前用户的
sessionVersion是否等于 Session 中保存的值 - 修改密码时，将该用户的 sessionVersion +1，并清空所有含旧 version 的 Session（Redis 可用 keys user:100:sess:* 批量删，或加一层映射表管理）
前端 JavaScript 能做什么？
前端无法主动使其他设备的 Session 失效，但可以配合后端提升体验：
立即学习“Java免费学习笔记（深入）”；
- 修改密码成功后，调用 /auth/logout-all 接口（由后端执行上述 Session 清理逻辑）
- 监听全局登出事件（如通过 WebSocket 或轮询 /auth/status），收到“会话被强制终止”响应后，自动跳转登录页并清空本地 token 或 Cookie
- 避免在 localStorage 存敏感凭证；若用了 JWT，确保它包含 version 声明，并在后端做
ver == user.sessionVersion校验
注意事项
不要依赖前端定时刷新或“悄悄退出”——这无法保证其他会话即时失效。真正可靠的机制必须由后端控制 Session 的有效性判定逻辑，且每次请求都执行该检查。
如果使用 Express + express-session + Redis，可在 session store 的 get 方法里注入校验逻辑；若用 JWT，就把 sessionVersion 放入 payload 并设较短过期时间，配合黑名单或实时 version 检查。
