Meta Refresh 不是真正的心跳机制，因其仅强制页面重载、不发异步请求、不复用连接、无法校验响应内容且丢失JS上下文；可靠心跳须用 fetch/XMLHttpRequest/EventSource。
Meta Refresh 不能可靠实现心跳监控，它本质是页面级强制重载，与“异步”“长连接”“低延迟心跳”在原理上冲突。真要监控服务端存活或维持连接状态，必须用 fetch、XMLHttpRequest 或 EventSource；<meta http-equiv="refresh"> 只适合极简场景下的粗粒度轮询（比如每 30 秒刷新整个页面看服务是否恢复），且副作用明显。
为什么 <meta http-equiv="refresh"> 不算心跳
它不发请求、不携带状态、不校验响应体、不复用连接，只是让浏览器丢弃当前 DOM 并重新发起完整页面 GET 请求：
- 每次触发都新建 TCP 连接（除非服务端支持 HTTP/2 复用且浏览器主动保持，但
refresh不控制这个） - 无法区分“服务响应了但内容异常”和“服务根本没响应”——只要返回了 HTTP 200（哪怕是个空页），页面就继续刷
- 无法设置请求头（如
Authorization、X-Heartbeat-ID），服务端没法做会话绑定或频率限制 - 页面刷新导致所有 JS 上下文丢失，
setTimeout、WebSocket 实例、未提交表单全部清空
如果非要用 HTML 层“模拟”，只能退化为页面存活探测
适用场景：内网管理页、无 JS 环境兜底、或仅需判断服务进程是否在监听端口（不关心业务逻辑是否健康）。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 把
<meta http-equiv="refresh" content="15">放在<head>中，content值设为略大于后端超时阈值（如后端 Nginx timeout=10s，则设 15） - 后端路由（如
/health）必须返回 HTTP 200 + 极简 HTML（避免大体积阻塞解析），例如：<!DOCTYPE html><html><body>OK</body></html>
- 不要依赖
<meta>的跳转能力（如content="15;url=/health"），部分浏览器对非同源 URL 会静默忽略 - 加
<meta name="robots" content="noindex,nofollow">防止被爬虫误刷
真正可行的 HTML 层心跳方案：纯 JS + Fetch
现代浏览器中，这是唯一兼顾异步、可控、可观察的方式。无需框架，几行代码即可：
let heartbeatTimer;
function startHeartbeat() {
fetch('/api/heartbeat', { method: 'HEAD' })
.then(r => {
if (r.ok) console.log('✅ Heartbeat OK');
else console.warn('⚠️ Heartbeat non-2xx:', r.status);
})
.catch(e => console.error('❌ Heartbeat failed:', e.message))
.finally(() => {
heartbeatTimer = setTimeout(startHeartbeat, 5000);
});
}
startHeartbeat();
关键点：
- 用
HEAD方法减少带宽消耗（服务端只需返回状态码，不用 body） - 避免用
GET+ 缓存（加cache: 'no-cache'或时间戳参数） - 务必用
.finally()启动下次定时器，防止请求卡住导致心跳中断 - 服务端需设置 CORS（
Access-Control-Allow-Origin: *或精确域名），否则跨域失败
注意：即使是最简 JS 方案，也要求浏览器支持 Fetch API（IE 完全不支持，需降级到 XMLHttpRequest）。若目标环境必须零 JS，那就没有真正的“心跳”可言——<meta refresh> 只是定时重载，别给它赋予它没有的能力。
