<meta http-equiv="refresh" content="5"> 实现每5秒强制重载当前页，不依赖JS、兼容性好但无状态控制；content值须为纯数字或“秒数;url=地址”（无空格），需配合cache-control: no-cache防缓存干扰。
用 meta 标签实现页面自动刷新，本质是强制重载当前 URL
直接写 <meta http-equiv="refresh" content="5"> 就能每 5 秒刷新一次，但要注意：这不是“监听文件变化后热更新”，而是浏览器按固定间隔向服务器重新请求整个页面。它不依赖 JavaScript，兼容性极好（IE6 都支持），但也因此缺乏控制力。
常见错误是漏写 content 值或格式不对——必须是纯数字（秒数），或者数字加分号再跟 url=...（用于跳转）。比如 content="3;url=/login" 表示 3 秒后跳转，而 content="3; url=/login"（带空格）在部分旧浏览器里会失效。
- 只刷新当前页：写成
content="10" - 跳转到其他地址：写成
content="2;url=https://example.com"，注意url=后不能有空格 - 想禁止缓存干扰刷新节奏？得额外加
<meta http-equiv="cache-control" content="no-cache">，否则某些代理或浏览器可能从缓存取页，导致“刷新”没效果
http-equiv="refresh" 在现代开发中为什么越来越少见
它无法区分“用户正在输入表单”和“页面就该刷新”——只要时间一到，所有未保存的输入、滚动位置、临时状态全丢。这对 SPA（如 React/Vue 应用）尤其危险，refresh 会直接销毁整个应用实例，而不是触发组件更新。
更实际的问题是调试困难：你没法在 DevTools 里打断点、查网络请求是否真发出了，因为它由浏览器底层调度，不走 JS 执行栈。而且，搜索引擎通常忽略这种跳转，对 SEO 没帮助，还可能被识别为恶意跳转而降权。
- 替代方案优先选
setInterval(() => location.reload(), 5000)，至少能加条件判断（例如只有当页面聚焦时才刷新） - 如果后端支持 SSE 或 WebSocket，用它们推通知比轮询刷新更省资源
- 开发阶段热更新（如 Vite/HMR）完全不走这个机制，那是构建工具在内存里替换模块，和
meta refresh毫无关系
Chrome/Firefox 对 refresh 的限制和实际表现差异
新版 Chrome（110+）对频繁 refresh 有静默干预：如果页面在后台标签页，且 content 值小于 3 秒，它可能直接忽略刷新指令。Firefox 则更宽松，但会把短间隔（≤1 秒）自动提升到最小 1 秒，避免疯狂请求。
另一个容易被忽略的点是相对路径处理：url=./dashboard 在当前 URL 是 https://site.com/admin/ 时，会解析为 https://site.com/admin/./dashboard，多数情况没问题；但如果当前 URL 是 https://site.com/admin（结尾无斜杠），结果就是 https://site.com/dashboard——路径解析逻辑和 <a href> 一致，但开发者常常没意识到这点。
- 跳转目标尽量用绝对 URL，避免路径歧义
- 测试时别只看前台标签页，切到后台再等几轮，确认行为是否符合预期
- 移动端 Safari 对
refresh支持稳定，但 iOS 的后台进程限制可能导致定时失效（页面被系统挂起）
真正需要自动刷新时，该先问自己三个问题
很多场景下，所谓“要自动刷新”，其实是没理清数据更新边界。比如监控页面每 10 秒拉一次新数据，完全不需要整页 reload，用 fetch + 局部 DOM 更新更可靠。
- 用户是否允许丢失当前操作上下文？如果答案是否定的，就别用
meta refresh - 后端能否提供增量数据接口（如返回 diff 而非全量 HTML）？能的话，JS 主动拉取 + patch 是更优解
- 这个刷新是给最终用户看的，还是给内部运维人员用的？后者可直接上命令行
curl+watch，比网页方案更轻量
最常被绕过的细节是：HTTP 响应头里的 Cache-Control 和 ETag 会覆盖 meta 的刷新行为。哪怕你写了 content="1"，如果响应头声明了 max-age=3600，浏览器仍可能缓存一小时——这个优先级高于 HTML 元素。
