JavaScript无法直接操作服务端Session，需通过拦截器识别401/403或自定义code（如1001）等失效信号，再跳转登录页并携带原路径；推荐编程式导航、加跳转锁，并区分Token与Session的清理方式。
JavaScript 本身无法直接操作服务端的 Session，Session 是服务端（如 Java Spring、Node.js Express 等）维护的状态机制。所谓“通过拦截器处理 Session 失效重定向”，本质是在前端发起请求时，由前端拦截响应，识别服务端返回的 Session 失效信号（比如 401、403 或特定 JSON 错误码），再执行跳转登录页等逻辑。
前端拦截器识别 Session 失效
现代前端常用 Axios 或 Fetch 封装请求层，在统一响应拦截器中判断 Session 是否失效：
- 服务端在 Session 过期时，通常返回 HTTP 状态码 401（Unauthorized）或 403（Forbidden），也可自定义业务码如 { "code": 401, "msg": "登录已过期" }
- Axios 示例：在
response.interceptors中检查 status 或 data.code - Fetch 不自带拦截器，需封装通用 fetch 函数，在
then(res => ...)中统一判断
触发重定向到登录页
检测到失效后，避免用户看到错误提示或空白页，应主动跳转：
- 使用
window.location.href = '/login?redirect=' + encodeURIComponent(window.location.pathname)带回原路径，登录后可跳回 - 若用 Vue Router / React Router，推荐编程式导航：
router.push('/login?redirect=...')，更可控且不强制刷新 - 注意避免重复跳转：可在跳转前加锁（如设置
isRedirecting = true），防止多个并发请求同时触发跳转
配合服务端返回明确失效标识
仅靠状态码不够健壮，建议服务端在响应头或响应体中显式标记：
立即学习“Java免费学习笔记（深入）”；
- 响应头添加
X-Session-Expired: true，前端可读取response.headers.get('X-Session-Expired') - 统一 JSON 响应结构，如
{ code: 1001, msg: '登录态无效', data: null }，约定 code=1001 表示 Session 失效 - 避免前端仅依赖 401——某些接口（如上传、下载）可能因权限返回 403，也需纳入失效处理范围
避免 Token 与 Session 混淆
注意区分：如果项目实际使用的是 JWT 或其他 Token 方案，那不是传统 Session，但失效处理逻辑类似：
- Token 过期一般由服务端校验后返回 401，前端同样拦截并跳转
- 区别在于 Token 通常存在 localStorage，而 Session ID 存于 Cookie；前者需前端清理 token，后者依赖服务端清 Cookie + 前端跳转
- 若服务端同时支持 Cookie Session 和 Token，需按实际鉴权方式约定失效响应格式
