javascript 无法直接操作服务端 session，需通过定时心跳请求（如 fetch）触发服务端自动续期；关键在于服务端启用 session middleware、配置 rolling: true，并确保请求携带有效 cookie（credentials: 'include'），前端配合 visibilitychange 等事件启停定时器。
JavaScript 中无法直接操作服务端 Session，但可以通过定时发起心跳请求（如 AJAX 或 Fetch），让服务端在每次收到请求时重置 Session 过期时间。关键在于：服务端必须在处理心跳请求时主动刷新 Session（例如更新其最后访问时间），而前端只需按需发送请求即可。
服务端需支持 Session 自动续期
Session 是否延期不取决于前端发没发请求，而取决于服务端如何处理该请求。常见框架中需确保：
- 心跳接口（如
/api/heartbeat）被纳入 Session 管理范围（即启用 session middleware / filter） - 服务端逻辑中不手动销毁或忽略 Session；默认情况下，多数框架（Express + express-session、Spring Session、ASP.NET Core）在收到带有效 Session ID 的请求时，会自动延长过期时间
- 检查配置项，例如 Express 中
rolling: true必须开启，否则 Session 不会自动滚动过期时间
前端用定时器发起心跳请求
在用户保持活跃期间，每隔小于 Session 过期时间的间隔（例如设为过期时间的 2/3）触发一次轻量请求：
- 使用
setInterval启动心跳，例如每 15 分钟请求一次（对应服务端 Session 过期时间为 20 分钟） - 请求可为 GET 或 POST，路径建议专用（如
/api/heartbeat），响应体只需简单成功标识（如{ ok: true }） - 监听用户交互（鼠标移动、键盘输入、页面可见性变化）来重置或暂停心跳，避免用户离开页面后仍无效续期
注意 Session ID 的传递与安全性
心跳请求必须携带有效的 Session 标识，否则服务端无法关联并续期：
- 若使用 Cookie 存储 Session ID（最常见），确保请求中
credentials: 'include'（Fetch）或withCredentials = true（XMLHttpRequest）已设置 - 避免在 URL 中传递 Session ID（不安全且易泄露），也不应手动读写 document.cookie 来拼接请求
- 确认跨域场景下服务端已正确配置 CORS，允许凭据（
Access-Control-Allow-Credentials: true）且 Origin 白名单精确匹配
补充：退出或休眠时停止心跳
提升资源利用与安全性：
- 监听
visibilitychange事件，在页面隐藏（document.hidden === true）时清除定时器；重新可见时恢复 - 监听
beforeunload或pagehide，发送最后一次心跳或通知服务端可能结束会话（可选） - 用户主动登出时，务必调用登出接口并清除本地凭证，同时停止心跳定时器
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
