最简单，因它不依赖JS、无需DOM加载、兼容所有浏览器，适用于纯静态404页；但需严格遵循content="秒数; url=目标"格式，分号后须空格，路径须为相对或绝对URL。
为什么直接用 meta http-equiv="refresh" 最简单
HTML 404 页面本质是静态资源，不依赖后端逻辑或 JavaScript 运行环境。用 <meta> 标签做跳转最稳妥——它在所有浏览器（包括禁用 JS 的场景）都生效，且无需等待 DOM 加载。
常见错误是把跳转写成 http-equiv="refresh" content="3;url=/index.html" 却漏掉单位（秒），或误写成 content="3,url=/index.html"（逗号应为分号）。注意：路径必须是相对或绝对 URL，不能是 ./index.html 这种相对路径写法（部分旧浏览器解析异常）。
- 推荐写法：
<meta http-equiv="refresh" content="5;url=/"> - 若需显示倒计时文字，必须配合 JavaScript（见下一条）
- 不要在
外使用该标签，否则无效
如何用 JavaScript 实现带倒计时文案的跳转
纯 meta 标签无法动态更新页面上的数字，要显示“3…2…1…正在跳转”就得靠 JS。但要注意：404 页面可能被搜索引擎抓取，JS 跳转对 SEO 不友好；且如果用户禁用 JS，倒计时就卡住不动。
关键点是把倒计时逻辑和跳转解耦：先渲染文案，再用 setTimeout 触发跳转，避免页面未加载完就跳走。
立即学习“前端免费学习笔记（深入）”；
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur
- 在
底部加一段内联脚本（避免阻塞渲染） - 用
document.getElementById找到占位元素，比如<span id="countdown">5</span> - 倒计时结束前调用
window.location.href = "/";，别用window.location.replace（会丢失后退历史）
<script>
const countdownEl = document.getElementById('countdown');
let seconds = 5;
const timer = setInterval(() => {
seconds--;
if (seconds <= 0) {
clearInterval(timer);
window.location.href = '/';
} else {
countdownEl.textContent = seconds;
}
}, 1000);
</script>
为什么不能用 history.pushState 或 router.push
404 页面不是单页应用（SPA）的路由上下文。在纯 HTML 404 页里调用 history.pushState 不会触发任何跳转，只会改地址栏 URL，且后续刷新仍返回 404；而 router.push 是 Vue Router / React Router 等框架 API，在没有对应 router 实例时直接报 ReferenceError: router is not defined。
更隐蔽的问题是：有些开发者试图在 404 页里引入完整前端框架代码来“补救”，这反而让页面体积暴增、首屏变慢，完全违背 404 页轻量、快速响应的设计原则。
- 确认你的 404 页面是否真由前端路由接管（如 Nginx 配置了
try_files $uri $uri/ /index.html;） - 如果是传统服务器直出的 404（如 Apache 的
ErrorDocument 404 /404.html），就别碰任何框架级跳转逻辑 - 检查控制台是否报
Uncaught ReferenceError—— 那说明你写了根本跑不起来的代码
服务端重定向比前端跳转更优先
如果你在 Nginx 或 Apache 中配置了 ErrorDocument 404 /404.html，但又在 /404.html 里写了 3 秒跳转，用户实际感知延迟是：请求 404 → 服务端返回 404.html（状态码仍是 404）→ 浏览器执行前端跳转。整个过程至少多花 1 个 RTT。
真正高效的方案是服务端直接 302 重定向到首页（比如 Nginx 的 error_page 404 =302 /;），但这就意味着你放弃自定义 404 页面内容。两者只能选其一：要体验（自定义页面 + 前端跳转），还是要性能（服务端重定向）。
- 用
curl -I https://yoursite.com/nonexistent检查响应头，确认状态码是 404 还是 302 - 如果看到
Location: /且状态码是 302，那前端倒计时根本不会执行 - SEO 建议保留 404 状态码并提供跳转，而不是偷偷改成 200 或 302
