不推荐。http-equiv="refresh"本质是页面级模拟跳转，无HTTP状态码语义、SEO权重不传递、存在白屏闪退风险、不支持HTTP头、易受浏览器兼容性与网络策略影响，现代开发应优先使用服务端301重定向。
用 http-equiv="refresh" 做重定向，现在还安全吗？
不推荐。现代浏览器虽仍支持 http-equiv="refresh"，但它本质是页面级模拟跳转，既无 HTTP 状态码语义（比如 301），也不被搜索引擎视为正规重定向，SEO 权重几乎不传递。更关键的是：它在页面加载完成前就触发，若用户网速慢或 JS 阻塞，可能看到白屏或闪退——尤其从旧域名跳新域名时，用户根本不知道发生了什么。
http-equiv="refresh" 的写法和致命缺陷
语法本身简单：。但这里的 content 值有两层风险：
-
0秒跳转：部分老浏览器（如 IE8）会忽略 0，降级为 1 秒；Chrome 93+ 对 0 秒刷新加了延迟干预，实际可能卡住 500ms+ -
url=后必须是绝对 URL：写成url=/path或相对路径会失败，且不会报错，只是静默失效 - 无法携带 HTTP 头：比如你想加
Cache-Control: no-cache或Strict-Transport-Security，meta 标签完全做不到
真正该用的方案：服务端 301 重定向
把跳转逻辑交给 Web 服务器，才是可靠、可追踪、SEO 友好的做法。常见配置如下：
- Nginx：
return 301 https://new.example.com$request_uri;（注意不是rewrite+permanent，后者性能略低且易循环） - Apache：
Redirect 301 / https://new.example.com/（放在.htaccess或虚拟主机配置中） - Cloudflare：在 Page Rules 中设 “Forwarding URL”，状态码选 “301 Permanent Redirect”
如果旧站已下线、只剩静态 HTML 文件，那只能退而求其次：用 http-equiv="refresh"，但务必补一行 JS 回退兜底：<script>location.replace("https://new.example.com"</script>，避免后退按钮卡在空白 meta 页面。
为什么很多人还在用 meta refresh？
因为改 DNS 或服务器配置需要权限，而扔一个 HTML 文件到旧空间最省事。但这恰恰埋了坑：当新域名启用 HTTPS 后，旧 HTTP 页面里的 meta refresh 会触发混合内容警告（Chrome 会直接拦截跳转）；更隐蔽的问题是，某些企业防火墙或校园网会过滤含 http-equiv="refresh" 的响应头，导致跳转彻底失效。
真要临时过渡，至少把 content 设为 "1; url=..."，给用户留出点击取消的机会——这点常被忽略。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
