meta http-equiv="refresh"仅适用于纯静态环境跳转、JS失效兜底、URL别名页等无状态场景，不支持条件判断，且存在格式敏感、SEO风险及无障碍缺陷。
meta http-equiv="refresh" 能做页面跳转，但仅限于简单、无交互、服务端不可控的场景。它不是重定向（HTTP 301/302），而是浏览器端的“延迟加载新 URL”，本质是放弃当前页面、拉取新资源。
什么时候该用 meta http-equiv="refresh"
只在以下情况考虑：
• 托管在纯静态环境（如 GitHub Pages、S3、Netlify 无服务端逻辑）且需跳转
• 需要 JS 完全失效时仍能 fallback（比如为禁用 JS 的用户兜底）
• 构建一个极简的 URL 别名页（如 https://a.com → https://b.com）
• 页面本身无状态、无表单、无滚动位置需要保留
别把它当登录后跳转或支付完成页的主力方案——它不感知用户行为，也不支持条件判断。
content 值写错就完全不跳
常见失效原因全是格式细节：
• content 中分号 ; 后不能有空格（"3;url=/login" ✅，"3; url=/login" ❌ 在旧 IE 和部分移动浏览器中失效）
• 必须带 url= 前缀，漏掉就变成刷新自身（"3" 是刷新，"3;url=/login" 才是跳转）
• 秒数支持小数（如 "1.5;url=/"），但 0 秒在 Chrome 110+ 会被屏蔽，报 Refresh is blocked due to user gesture requirement
• url 值不能含未编码的空格或中文（url=/搜索 必须写成 url=/%E6%90%9C%E7%B4%A2）
立即学习“前端免费学习笔记（深入）”；
和 JavaScript 跳转共存时谁赢
window.location.href 或 location.replace() 一旦执行，会立即终止 meta refresh 计时器——没有竞态，JS 永远优先。
但陷阱在于：如果 JS 是异步触发（比如等 API 返回再跳），而 meta 设了 2 秒，API 卡住 3 秒，meta 就先跳了。
所以：
• 不要混用“条件跳转”逻辑（如登录态判断）和 meta refresh
• 若必须共存，把 JS 跳转逻辑放在 <head> 里尽早执行，或直接删掉 meta 标签
• location.replace() 比 location.href = 更干净，避免用户点「返回」回到空白跳转页
SEO 和可访问性实际影响
搜索引擎能识别 meta refresh，但 W3C 明确建议延迟 ≥ 5 秒；短于 1 秒可能被 Google 当作“伪装”（cloaking）降权。
屏幕阅读器不会播报倒计时，也不会暂停跳转——对视障用户不友好。
更关键的是：它不触发 beforeunload，用户填了一半表单就跳走了，毫无提示。
如果你的页面有输入框、文件上传、或任何未持久化的操作，meta refresh 就不该出现。
