javascript无法直接控制服务端session超时，但可通过定期探测（如每15分钟调用/api/session/valid）、响应拦截（捕获401/403）、用户交互心跳保活（防抖调用/api/session/refresh）及超时提醒跳转，实现对会话超时的感知与优雅响应。
JavaScript 本身无法直接控制服务器端的 Session 超时逻辑，因为 Session 是服务端（如 Node.js、Java、PHP 等）维护的状态。但前端可以通过主动探测、心跳保活、超时提醒和自动重定向等方式，配合后端实现“感知并响应”会话超时，提升用户体验。
理解 Session 超时的本质
Session 超时由服务端设定（例如 Express 默认 24 小时，Spring Boot 常设 30 分钟），浏览器关闭或长时间无请求后，服务端会清除 Session 数据。此时用户再发请求，后端通常返回 401 Unauthorized 或 403 Forbidden，或跳转到登录页。前端 JavaScript 的任务是：提前预判、及时反馈、平滑恢复。
前端主动检测会话是否有效
不依赖用户点击才触发验证，而是定期用轻量接口探测 Session 状态：
- 向后端发起一个无需参数的 GET 请求（如
/api/session/valid），后端仅校验 Session 是否存在且未过期，返回{ valid: true }或{ valid: false } - 使用
setInterval每 5–10 分钟检查一次（略短于后端超时时间，例如后端设 20 分钟，前端每 15 分钟查一次） - 若返回无效，立即弹出提示，并清空本地敏感数据（如 token 缓存、用户信息），跳转至登录页
发送请求时实时拦截过期响应
所有通过 fetch 或 axios 发出的请求，统一添加响应拦截器：
- 检查响应状态码是否为 401 / 403，或响应体中包含
sessionExpired: true等自定义字段 - 捕获后，停止后续请求，显示“登录已过期，请重新登录”，并跳转登录页（避免重复弹窗，可用标记位防多次触发）
- 对登录接口本身不做拦截，确保用户能正常重新认证
用户操作时刷新服务端 Session（心跳保活）
只要用户在页面上有交互（点击、滚动、键盘输入等），就向服务端发起一次“刷新 Session”请求（如 POST /api/session/refresh），让服务端重置 Session 的最后访问时间：
- 监听
document的mousemove、keydown、scroll、click等事件 - 使用防抖（debounce）控制频率，例如 5 分钟内只发一次刷新请求，避免高频打扰服务端
- 注意：该机制需后端支持（调用
req.session.touch()或等效方法），否则无效
不复杂但容易忽略的是前后端超时时间的协同——前端探测间隔和服务端 timeout 应错开，且前端跳转前最好先尝试静默刷新一次 Session，给用户多几秒缓冲。关键不在“阻止过期”，而在“让用户无感地续期或优雅地重登”。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
