用meta标签实现定时刷新或跳转，本质是浏览器将解析为等效http响应头refresh，不依赖js、兼容性好但无状态控制、不可取消且seo不友好。
用 meta 标签实现页面定时刷新或跳转，本质是伪造 HTTP 响应头
浏览器解析到 <meta http-equiv="refresh" content="5"> 时，会等同于收到服务端返回的 Refresh: 5 响应头——它不是 JavaScript，不依赖执行环境，但也不受现代安全策略保护（比如 CSP 默认不限制它）。这意味着：它在禁用 JS 的浏览器里仍有效，但在某些严格 CSP 策略下可能被拦截（取决于 refresh 是否在 frame-ancestors 或 navigate-to 白名单中）。
content 参数必须同时指定秒数和可选 URL，格式不能错
常见错误是只写秒数，或 URL 缺少引号、协议不全，导致跳转失败或跳到错误路径：
-
content="3"→ 页面每 3 秒刷新一次（当前 URL） -
content="3; url=/dashboard"→ 3 秒后跳转到相对路径/dashboard -
content="0; url=https://example.com"→ 立即跳转（常用于旧式登录后重定向） -
content="5;url=login.html"→ ❌ 缺空格，部分老浏览器可能忽略整条 meta -
content="5; url=//other-site.com"→ ❌ 协议相对 URL 在某些场景下触发跨域限制或被拦截
与 JavaScript 跳转相比，meta refresh 没有回调、无法取消、不记录历史
它是一次性声明，一旦插入 DOM 就生效，无法像 setTimeout 那样 clearTimeout，也不能监听跳转前事件。典型影响包括：
- 用户点「返回」时，可能直接回到上一页，而不是停在刷新中的当前页（因为没产生新 history entry）
- 调试时看不到跳转触发点，只能查 DOM 中是否存在该
meta标签 - SEO 不友好：搜索引擎可能将跳转页视为弱相关，尤其
content="0"易被判定为跳转作弊 - 移动端 WebView（如微信内置浏览器）有时会忽略
meta refresh，优先走 JS 方案
真正需要自动跳转时，优先用 HTTP 响应头而非 meta
如果后端可控，直接返回 Refresh: 3; url=/done 响应头更可靠——它绕过 HTML 解析阶段，不受标签位置、JS 阻塞或 DOM 加载顺序影响。只有在静态页、纯前端托管（如 GitHub Pages）、或 CMS 输出不可控时，才退而求其次用 meta。注意：meta 必须放在 内且在 <title></title> 之后、其他 meta 之前，否则部分 IE 版本可能不识别。
