<meta http-equiv="refresh">用于页面自动刷新或跳转，解析时即注册定时器，5秒后重载本页写为content="5"，3秒后跳转写为content="3;url=/dashboard"，分号后不可有空格，仅首次加载生效且不可取消。
meta refresh 的基本写法和触发时机
页面自动刷新靠的是 <meta http-equiv="refresh">，它模拟 HTTP 头部的 Refresh 指令。浏览器解析到这个标签后，会在指定秒数后重新加载当前页（或跳转到新地址）。注意：它只在页面首次加载时生效一次，不是定时轮询；刷新行为由浏览器主动执行，不依赖 JavaScript。
- 刷新当前页：写成
<meta http-equiv="refresh" content="5">，表示 5 秒后重载本页
- 跳转并刷新：写成
<meta http-equiv="refresh" content="3;url=/dashboard">，3 秒后跳转到 /dashboard
- content 值必须是数字（秒）开头，后面分号 + url= 是可选部分；中间不能有空格，
content="5 ; url=..." 会失效
为什么页面没刷新？常见失效原因
很多情况下写了 meta 却没反应，问题往往不在语法本身：
- 页面已存在多个
<meta http-equiv="refresh">，浏览器只认第一个，后面的被忽略
- 刷新时间设为 0（
content="0"），某些浏览器（如 Safari）会拒绝执行，视为潜在重定向攻击
- 页面通过
history.pushState() 或前端路由改变了 URL，但 meta 标签仍指向原始路径，刷新后回到初始路由而非当前视图
- 服务器返回了
Cache-Control: no-cache 或 Pragma: no-cache，导致浏览器跳过缓存但未触发刷新逻辑（实际不影响 meta refresh，但容易让人误判）
与 JavaScript location.reload() 的关键区别meta refresh 和 JS 的 location.reload() 表现不同，选错会导致体验偏差：
-
meta refresh 是声明式、不可取消的，一旦写入 HTML 就无法用 JS 中断（除非 DOM 动态移除该标签）
-
location.reload() 是命令式、可编程的，能加条件判断、延迟执行、甚至传参 location.reload(true) 强制绕过缓存
- 页面内嵌 iframe 时，
meta refresh 只作用于顶层文档；而 JS 可精确控制 iframe.contentWindow.location.reload()
- SEO 场景下，搜索引擎爬虫通常忽略
meta refresh（尤其 content="0"），但会记录 JS 调用，这点影响不大，但需知悉
实际项目中更推荐的替代方案
纯 meta refresh 在现代前端开发中已属边缘用法，真正需要自动更新的场景（如监控页、报表页），应优先考虑：
- 用
fetch() + setInterval() 拉取数据，局部更新 DOM，避免整页闪烁
- 后端提供 SSE（Server-Sent Events）或 WebSocket，实现服务端主动推送变更
- 若必须整页刷新，用
setTimeout(() => location.reload(), 60000) 替代 meta，便于调试、暂停、加日志
- 静态生成站点（如 Jekyll、Hugo）中，meta refresh 仍有价值——无需 JS 运行环境，适合极简部署
<meta http-equiv="refresh" content="5">，表示 5 秒后重载本页 <meta http-equiv="refresh" content="3;url=/dashboard">，3 秒后跳转到 /dashboard content="5 ; url=..." 会失效 - 页面已存在多个
<meta http-equiv="refresh">，浏览器只认第一个，后面的被忽略 - 刷新时间设为 0（
content="0"），某些浏览器（如 Safari）会拒绝执行，视为潜在重定向攻击 - 页面通过
history.pushState()或前端路由改变了 URL，但 meta 标签仍指向原始路径，刷新后回到初始路由而非当前视图 - 服务器返回了
Cache-Control: no-cache或Pragma: no-cache，导致浏览器跳过缓存但未触发刷新逻辑（实际不影响 meta refresh，但容易让人误判）
与 JavaScript location.reload() 的关键区别meta refresh 和 JS 的 location.reload() 表现不同，选错会导致体验偏差：
-
meta refresh 是声明式、不可取消的，一旦写入 HTML 就无法用 JS 中断（除非 DOM 动态移除该标签）
-
location.reload() 是命令式、可编程的，能加条件判断、延迟执行、甚至传参 location.reload(true) 强制绕过缓存
- 页面内嵌 iframe 时，
meta refresh 只作用于顶层文档；而 JS 可精确控制 iframe.contentWindow.location.reload()
- SEO 场景下，搜索引擎爬虫通常忽略
meta refresh（尤其 content="0"），但会记录 JS 调用，这点影响不大，但需知悉
实际项目中更推荐的替代方案
纯 meta refresh 在现代前端开发中已属边缘用法，真正需要自动更新的场景（如监控页、报表页），应优先考虑：
- 用
fetch() + setInterval() 拉取数据，局部更新 DOM，避免整页闪烁
- 后端提供 SSE（Server-Sent Events）或 WebSocket，实现服务端主动推送变更
- 若必须整页刷新，用
setTimeout(() => location.reload(), 60000) 替代 meta，便于调试、暂停、加日志
- 静态生成站点（如 Jekyll、Hugo）中，meta refresh 仍有价值——无需 JS 运行环境，适合极简部署
meta refresh 是声明式、不可取消的，一旦写入 HTML 就无法用 JS 中断（除非 DOM 动态移除该标签） location.reload() 是命令式、可编程的，能加条件判断、延迟执行、甚至传参 location.reload(true) 强制绕过缓存 meta refresh 只作用于顶层文档；而 JS 可精确控制 iframe.contentWindow.location.reload() meta refresh（尤其 content="0"），但会记录 JS 调用，这点影响不大，但需知悉 - 用
fetch()+setInterval()拉取数据，局部更新 DOM，避免整页闪烁 - 后端提供 SSE（Server-Sent Events）或 WebSocket，实现服务端主动推送变更
- 若必须整页刷新，用
setTimeout(() => location.reload(), 60000)替代 meta，便于调试、暂停、加日志 - 静态生成站点（如 Jekyll、Hugo）中，meta refresh 仍有价值——无需 JS 运行环境，适合极简部署
meta refresh 看似简单，但它的不可控性和对用户操作的打断性，在表单未提交、编辑中内容未保存等场景下极易引发数据丢失。真要用，务必确认页面状态可安全丢弃。
