meta refresh 跳转需严格匹配 content="秒数;url=目标" 格式，秒数支持小数但低于1秒Chrome强制100ms延迟，0秒跳转存在兼容与拦截风险；相对路径以HTML物理位置为基准；SPA中应避免使用以防绕过路由；SEO不传递权重且可能造成重复内容；用户侧无提示、不可取消、bfcache失效；生产环境须JS兜底并处理可见性与输入状态。
content="秒数; url=目标" 格式必须严格匹配
写错一个字符就会静默失效，比如 content="3;url=/home" ✅，但 content="3 ; url=/home" ❌（分号后空格）、content="3,url=/home" ❌（逗号）、content="3; /home" ❌（漏掉 url= 前缀）。浏览器不会报错，只会当普通 meta 忽略。
秒数支持小数（如 "2.5;url=/next"），但低于 1 秒时 Chrome 93+ 会强制延迟至少 100ms，且 SEO 可能直接降权。0 秒跳转虽可行（content="0;url=https://new.com"），但部分旧 WebView 会忽略，新浏览器也可能拦截——尤其当页面还没获得焦点时。
相对路径以当前 HTML 文件位置为基准
很多人以为 url=./about.html 是“相对于当前 URL”，实际是相对于当前 HTML 文件在服务器上的物理路径。例如页面地址是 https://a.com/app/v2/index.html，那么：
-
url=./about.html→ 解析为https://a.com/app/v2/about.html -
url=/about.html→ 解析为https://a.com/about.html -
url=about.html→ 解析为https://a.com/app/v2/about.html（同第一种）
在单页应用（SPA）里混用这个标签，容易绕过前端路由，导致样式丢失或状态重置。如果目标是 SPA 内部路由（如 /dashboard），别用 meta refresh，改用 JS 跳转并触发路由导航。
立即学习“前端免费学习笔记（深入）”；
把任意文章或文档内容转换成精美的全屏翻页 HTML 演示文件（幻灯片风格）。当用户发来一篇文章、文档链接、Markdown 内容、或粘贴的文本，并且希望生成演示用的 HTML 时触发。支持任意内容来源：iWiki 链接、KM 链接、本地文件路径、直接粘贴的文本。生成的 HTML 文件保存到本地工作区，并通过企微直接发送给用户。触发词示例：帮我把这篇文章做成PPT、转成演示文档、生成HTML幻灯片、做个演示、转成可以演示的格式、article to deck、make a slide。
它不等同于 HTTP 301，SEO 和用户行为都受影响
搜索引擎不把 meta http-equiv="refresh" 当作正规重定向，权重几乎不传递，还可能同时索引源页和目标页，造成重复内容。W3C 明确建议：仅在必要时使用，且延迟不少于 5 秒；Google 对 ≤1 秒的跳转视为可疑行为。
用户侧问题更实际：跳转前无提示、无法取消、点「返回」可能看到白屏（Chrome 95+ 已禁用 bfcache）、切到其他标签页后仍倒计时——这些都不是 bug，而是设计如此。如果你需要倒计时文案、暂停按钮或检测用户是否还在输入，meta refresh 就不该是首选。
生产环境别只靠它，得加 JS 兜底
单独放一个 <meta http-equiv="refresh" content="5; url=/login"> 是高风险行为。更稳妥的做法是双保险：
- 在
放保底 meta，覆盖 JS 禁用或加载失败场景 - 在
底部加轻量 JS：setTimeout(() => location.replace('/login'), 5000) - 监听
visibilitychange，页面切走时暂停倒计时（需配合 clearTimeout + 重新 setTimeout） - 若页面有表单，检查
document.activeElement，避免打断用户输入
真正难处理的不是怎么跳，而是“该不该跳”——这个判断逻辑 meta 标签天生不具备，必须由 JS 承担。
