不会直接阻塞html解析，但会强制中断页面生命周期，导致dom丢弃、请求重发、重新渲染，等效于用户手动f5；content格式须为“秒数; url=目标地址”，chrome 93+对无用户交互的跳转会静默拦截。
网页自动刷新用 <meta http-equiv="refresh"> 会阻塞页面加载吗？
不会直接阻塞，但会强制中断当前页面生命周期——浏览器在解析到该标签后，会在指定时间后丢弃当前 DOM、重发请求、重新渲染。实际效果等同于用户手动按了 F5。
常见错误是把刷新时间设为 0 却没配 url，结果页面白屏且控制台无报错，只留下一个空载状态。
- 刷新必须写全两个属性：
content值格式为"秒数; url=目标地址"，例如<meta http-equiv="refresh" content="5">表示 5 秒后刷新当前页 - 若要跳转，
url必须是合法路径，相对路径以当前页为基准，url=/admin和url=admin/行为完全不同 - Chrome 93+ 对非用户交互触发的自动跳转（包括 meta refresh）有更严格限制：若页面未获得焦点或未发生过用户操作，部分跳转可能被静默拦截
http-equiv="refresh" 与 JavaScript location.reload() / location.href 的关键区别
meta 标签是声明式、无脚本依赖的方案，适合纯静态页或服务端无法注入 JS 的场景；JS 方式则可控性更强，能加条件判断、埋点、防重复触发。
但别忽略兼容性现实：某些老旧内网系统（如基于 IE11 的政务终端）禁用 JS，此时 meta 是唯一选择；而现代 PWA 应用里用 meta 刷新反而会破坏 service worker 缓存策略。
- meta 刷新无法取消，一旦写入 HTML 就生效；JS 可用
clearTimeout或标志位控制 - meta 不支持传参或携带 headers；JS 跳转可拼 query、用
postMessage通信 - SEO 层面，Google 明确表示对
http-equiv="refresh"的跳转会降权处理，尤其当content中秒数 ≤ 1 时，可能被视作作弊
如何避免 <meta http-equiv="refresh"> 导致的循环跳转？
最典型的情况是 A 页面跳 B，B 页面又写了跳回 A 的 meta 标签，用户卡在两页间反复横跳——浏览器不会警告，只会不断重载。
根本解法不是加延时，而是切断源头：确保跳转目标页不包含相同刷新逻辑，或用 URL 参数标记状态。
- 服务端渲染时，检查
request.url是否含?refreshed=1，有则不输出该 meta 标签 - 静态页可用简单规则：只在首页或登录页放刷新，详情页、表单页一律禁止
- 调试时快速验证：打开开发者工具 → Network 面板，看跳转后的请求 URL 是否带重定向链（
302或307），若全是200+ meta，则大概率是前端循环
移动端 Safari 和 Chrome for Android 对 refresh 的特殊限制
iOS 15+ 的 Safari 默认屏蔽所有非用户手势触发的页面跳转，哪怕 meta 写了 content="0; url=xxx"，也可能只刷新当前页甚至完全忽略。
Android 上问题更隐蔽：部分定制 ROM（如华为 EMUI、小米 MIUI）会主动拦截 meta refresh，表现为页面“卡住”，但 network 里能看到资源仍在加载，只是 DOM 不更新。
- 绕过方案有限，优先改用 JS +
visibilitychange事件监听页面可见性，再决定是否跳转 - 若必须用 meta，请确保
content值 ≥ 3 秒，且目标页响应头中不含Cache-Control: no-cache，否则容易触发离线白屏 - 永远不要在 PWA 的
index.html里写自动跳转 meta，service worker 会缓存它，导致后续更新失效
head() 函数），就完全不起作用。前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
