JavaScript无法直接设置服务端Session超时，需通过监听用户行为重置倒计时、提前预警续期、轻量心跳保活及敏感操作二次校验来协同实现会话控制。
JavaScript 本身不能直接设置或修改服务端 Session 的超时时间，它只能通过监听用户行为、发起心跳请求、管理本地倒计时等方式，配合后端协同实现“长时间不操作”的会话控制。核心逻辑是：前端感知活跃状态 + 主动保活 + 友好提醒 + 安全兜底。
监听用户操作重置倒计时
页面无操作超时，本质是“用户静默”而非“技术失效”。前端需捕获真实交互信号：
- 监听 mousemove、keydown、scroll、click、focus 等事件，任一触发即重置本地计时器
- 避免只监听 click —— 用户可能只是阅读、滚动、切换标签页，这些也应视为活跃
- 使用
setTimeout或setInterval维护一个倒计时变量（如idleSeconds = 0），每秒递增，达到阈值（如 1800 秒 = 5 分钟）即准备预警
提前预警 + 手动续期确认
不要等 Session 突然失效才跳转登录页，这会导致数据丢失和体验断裂：
- 在倒计时剩 2–5 分钟时，弹出非阻断式提示：“会话将在 X 分钟后过期，是否继续？”
- 按钮提供“延长会话”（调用
/api/keep-alive）和“安全退出”两个明确选项 - 点击“延长会话”后，前端发起一次认证凭证有效的请求，后端刷新 Session 最后访问时间并返回成功标识
- 若用户未响应，倒计时归零后自动登出；若网络异常或接口失败，按本地策略降级处理（如强制跳转登录）
心跳保活要轻量且可靠
单纯靠定时器续期有风险——用户关掉标签页、切到其他应用、断网时，前端无法感知，但服务端仍在续期，造成资源浪费与安全漏洞：
立即学习“Java免费学习笔记（深入）”；
- 心跳请求必须携带有效凭证（如 Cookie 中的
JSESSIONID或 Header 中的Authorization） - 间隔建议设为服务端 Session 超时时间的 80%～90%（例如后端设 8 小时，前端每 7 小时 15 分钟发一次）
- 心跳接口应极轻量（返回
{ ok: true }即可），不查权限、不加载数据、不写日志 - 搭配 visibilitychange 事件：页面不可见时暂停心跳，可见时恢复，并检查当前会话是否仍有效
敏感操作必须二次校验
超长会话不等于高信任度。政务、金融类系统中，即使 Session 未过期，关键动作仍需增强验证：
- 提交电子签章、修改身份信息、发起支付前，必须弹窗要求短信验证码、人脸识别结果或 UKey 签名响应
- 该验证过程独立于 Session 生命周期，每次调用都需后端实时核验，不可缓存结果
- 后端记录完整上下文：设备指纹、IP、操作时间、Session ID、二次认证方式及结果，用于审计追溯
