meta http-equiv="refresh" 不能用于心跳监控，因其仅为页面重载指令，不发送HTTP请求、无法感知连接状态、无响应校验与重连逻辑，且会导致表单丢失和体验崩溃。
meta http-equiv="refresh" 不能用于实现心跳监控——它只做页面级跳转或刷新，不产生网络请求，也不提供连接状态反馈，和 WebSocket 或 HTTP 长连接的心跳机制完全无关。
为什么 meta refresh 不是心跳方案
它本质是浏览器的页面重载指令，不是网络层探测手段：
• 不发送任何 HTTP 请求到服务端（除非 url= 指向新地址，那也只是 GET，且无法携带心跳语义）
• 无法判断连接是否存活：即使 WebSocket 已断开、HTTP 连接被中间设备关闭，meta refresh 仍会准时触发，毫无感知能力
• 无超时控制、无响应校验、无重连逻辑，纯单向计时器行为
• 服务端收不到“心跳信号”，自然无法刷新会话、更新 last_seen 时间或触发保活策略
表单场景下误用 meta refresh 做心跳的典型错误
有人试图用 content="120;url=/api/heartbeat" 让浏览器每 2 分钟“访问一次心跳接口”，但这实际导致：
• 页面被强制跳转或刷新，用户正在填写的表单数据直接丢失
• 每次跳转都重建 DOM 和 JS 上下文，定时器、WebSocket 实例、事件监听器全被销毁
• 服务端收到的是普通 GET 请求，无法区分是心跳还是真实导航，也无法关联会话 ID（尤其无 Cookie 或 Token 上下文时）
• 若接口返回非 HTML 内容（如 JSON），浏览器可能报错或空白页，体验崩溃
真正可用的轻量级替代方案（无 WebSocket 时）
当后端不支持 WebSocket，又需维持 HTTP 会话活跃，应使用前端主动发起的、可控制的异步请求：
• 用 setInterval + fetch('/api/heartbeat', { method: 'POST', credentials: 'include' })，确保携带会话凭证
• 心跳接口必须返回明确状态码（如 204 No Content），避免响应体解析开销
• 每次成功响应后重置失败计数；连续失败 N 次（如 3 次）则提示用户“连接异常”，而非静默等待
• 结合 document.hasFocus() 和 visibilitychange 事件，在页面不可见时暂停心跳，省资源也防误判
• 若表单有未保存内容，心跳失败时应弹出提示并暂停自动提交逻辑，而不是直接跳转
关键区别点：心跳要闭环，meta refresh 是开环
有效心跳必须形成“发—等—收—判”闭环：
• 发：带唯一 trace ID 或时间戳的请求
• 等：设置合理 timeout（如 8 秒），防卡死
• 收：检查 status、headers（如 X-Session-Valid: true）、body 语义
• 判：更新本地 lastHeartbeatTime，驱动重连或 UI 状态变更
而 meta refresh 只有“发”（其实是 reload），没有“等”和“收”，更无“判”。它连心跳的边都没沾上。
