<meta http-equiv="refresh"> 的 content 值必须严格写作“秒数;url=目标地址”，分号后不可有空格，url=前缀缺一不可；仅写数字表示刷新当前页，0秒跳转在现代浏览器中常被拦截。
能实现，但只适合无状态、无交互、服务端不可控的极简场景；现代浏览器对 0 秒跳转普遍拦截，content 格式稍错就完全不生效。
meta http-equiv="refresh" 的 content 值怎么写才有效
必须严格按 "秒数;url=目标地址" 格式，且分号后不能有空格（旧 IE 和部分安卓 WebView 会失效），url= 前缀缺一不可。
-
content="3;url=/login"✅ 正确：3 秒后跳到根路径/login -
content="3; url=/login"❌ 失效：分号后空格导致旧浏览器忽略 -
content="3;url=/login?next=%2Fdashboard"✅ 支持 URL 编码参数 -
content="3"❌ 不是跳转，是刷新当前页 -
content="0;url=/new"⚠️ Chrome 110+ 会报Refresh is blocked due to user gesture requirement，实际不跳
相对路径在 meta refresh 中如何解析
浏览器始终以当前 HTML 文件所在 URL 为基准解析 url= 后的路径，不是以当前显示地址或 JS 修改过的 location.href 为准——这点极易踩坑。
- 当前页 URL 是
https://a.com/app/sub/page.html，写url=../index.html→ 跳到https://a.com/app/index.html - 写
url=/index.html→ 跳到https://a.com/index.html（绝对路径） - 写
url=index.html→ 跳到https://a.com/app/sub/index.html（相对路径） - 单页应用（SPA）中混用此方式，会绕过路由系统，丢失状态、样式错乱、
history.back()失效
和 JavaScript 跳转共存时谁起作用
window.location.href 或 location.replace() 一旦执行，立刻终止 meta refresh 计时器；但 JS 是异步的，而 meta 是静态声明的，二者没竞态，只有“谁先触发谁赢”。
- 若页面写了
content="2;url=/fallback"，又在 JS 中setTimeout(() => { location.replace('/success') }, 3000)→ 先跳/fallback，JS 还没执行完 - 若 JS 在
就同步执行跳转，则meta根本不会启动 - 不要用
meta做登录态判断后的跳转——它无法读 cookie、不等 API、不校验权限 - 真正需要条件逻辑时，删掉
meta，只用 JS；若需 JS 失效兜底，再补一个带合理延迟（≥5 秒）的meta
为什么跳转后页面白屏或反复重定向
最常见原因是循环跳转：A 页面 meta 跳 B，B 页面也写了跳 A 的 meta，浏览器不会提示，只会不断丢弃 DOM、重发请求、重新渲染，Network 面板里全是 200 状态。
- 调试时看 Network → Headers，确认跳转后是否出现
301/302（服务端重定向）；若全是 200 + 新 HTML，大概率是前端循环 - 静态页可加简单规则：只在首页、维护页、别名页放
meta，表单页、详情页、支付完成页一律禁用 - 服务端渲染时，可用 URL 参数标记（如
?redirected=1），后端检测到即不输出该meta标签 -
meta refresh无法取消、无法携带 headers、不触发beforeunload——用户填一半表单就跳走，毫无提示
真正关键的不是“能不能跳”，而是“该不该用”。只要服务端能配 301/302，或前端能跑 JS，meta http-equiv="refresh" 就只是个降级选项。它的容错极低，格式敏感，SEO 友好度差，无障碍支持缺失——这些不是边缘问题，是默认行为。
