meta refresh 二次跳转会绕过前端路由，导致SPA中样式丢失、状态清空、history.back()失效；其跳转不经过Vue/React Router，而是直接丢弃DOM重建页面，且Chrome 93+会静默拦截无用户交互的自动跳转。
meta refresh 二次跳转会绕过前端路由
单页应用（SPA）里混用 meta http-equiv="refresh"，跳转目标不会经过 Vue Router 或 React Router，而是直接丢弃当前 DOM、重新加载 HTML 文件。结果是：样式丢失、状态清空、history.back() 返回空白页或错误路径。
典型表现：/user/123 页面写了 content="3;url=/dashboard"，跳过去后地址栏变成 /dashboard，但页面只显示根组件的默认内容，CSS 没加载，Vuex/Pinia 状态为空。
- 根本原因是浏览器把
url=当作全新 HTML 请求，不走 JS 路由拦截 - 相对路径按 HTML 文件所在位置解析，不是当前 URL —— 比如部署在
/app/index.html，url=./home就跳到/app/home，而非你期望的/home - 若服务端没配 fallback（如 Nginx 的
try_files $uri $uri/ /index.html;），跳转后直接 404
和服务端重定向共存时谁生效？
两者不冲突，但行为完全不同：302 响应头是 HTTP 层重定向，浏览器在收到响应前就已决定跳转；而 meta refresh 是 HTML 解析完才注册的客户端定时器。如果服务端返回了 302，meta 根本没机会执行。
但容易出问题的是「服务端跳转后，目标页又写了 meta refresh」——比如登录接口返回 302 → /dashboard，而 /dashboard 页面自己又带 content="5;url=/profile"，用户刚进 dashboard 就被二次踢走。
- 这种链式跳转无法被前端拦截或取消，
clearTimeout对它无效 - Network 面板里看不到重定向链（全是 200），只能靠手动检查每页 HTML 源码
- 若服务端跳转用了
307（保留 method/body），而meta又指向 GET 地址，可能造成表单重复提交
Chrome 93+ 对无交互跳转的静默拦截
现代 Chrome（93 起）要求自动跳转必须有用户手势触发，否则直接屏蔽。哪怕你写的是 content="0;url=/success"，只要页面没获得过焦点、没响应过 click 或 keydown，就会静默失效，控制台只报 Refresh is blocked due to user gesture requirement，不跳也不报错。
- 这个限制对 SPA 尤其致命：首屏渲染完成前，JS 还没挂载事件，
meta已经倒计时完了 - Firefox 把
content="0.5"自动提升到 1 秒，后台标签页下content<3直接忽略 - 微信 WebView 和部分 iOS Safari 版本会完全跳过
meta refresh，尤其content="0"场景
真正要防的是循环跳转和白屏卡死
最隐蔽的风险不是跳不跳得成，而是跳进去出不来：A → B → A 这种循环，浏览器不会警告，只会反复丢弃 DOM、重发请求、重新渲染，Network 面板里全是 200，F12 看不到异常，用户只觉得页面卡顿、白屏、反复闪。
- 常见诱因：登录页跳首页，首页又根据未登录态跳回登录页；维护页跳主站，主站检测到维护模式又跳回维护页
-
content="0"在服务端响应慢时极易白屏——HTML 没加载完，meta计时器已启动，浏览器强行 reload 空白页 - CSP 若没配
frame-ancestors或禁了meta，该标签会被静默屏蔽，连控制台提示都没有
真要用，只限纯静态页或 JS 被策略禁用的老旧内网系统；其他场景，删掉 meta，改用 location.replace() + 条件判断，才是可控解法。
