404页面中用meta refresh跳转无效，因服务器已返回404状态码，该标签仅浏览器端执行，搜索引擎和爬虫忽略，无法传递权重或改变响应状态；正确做法是服务端返回301/302并设置Location头。
404页面里用跳转是否有效
无效。浏览器在返回 404 状态码时，<meta http-equiv="refresh"> 仍会执行跳转，但搜索引擎和部分客户端（如 curl、某些爬虫）完全忽略该标签，只认 HTTP 状态码。你看到的“跳转成功”，只是浏览器渲染了错误页后又刷新了一次——实际仍是 404 响应，SEO 友好性为零，且无法传递原始请求路径。
服务端返回 302 或 301 跳转才是正确做法
真正的 404 自动跳转必须由服务端控制响应状态码和 Location 头。前端 HTML 无法改变已发出的 404 响应状态。
- Nginx：在
server或location块中加error_page 404 /404.html;是静态兜底，不跳转；要跳转得用return 302 https://example.com/;或配合try_files - Apache：用
RewriteRule ^ - [R=302,L]配合RewriteCond %{REQUEST_FILENAME} !-f判断文件不存在 - Node.js（Express）：
app.use((req, res) => res.redirect(302, '/'))必须放在所有路由之后，否则会覆盖正常路由
纯静态托管（如 GitHub Pages、Vercel Static）怎么处理
这类平台不支持自定义 404 响应头，但允许返回一个 404.html 文件。此时唯一可行的折中方案是：确保该文件存在，并在其中用 JavaScript 检测当前 URL 是否为真实路径，再决定是否跳转。
示例（放入 404.html）：
立即学习“前端免费学习笔记（深入）”；
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
<script>
// 不跳转根路径、常见资源后缀，避免死循环
const isResource = /(\.\w{2,4})$/.test(window.location.pathname);
if (!isResource && window.location.pathname !== '/') {
window.location.href = '/';
}
</script>注意：这个逻辑不能替代服务端跳转，它只是用户体验补救——HTTP 状态码仍是 404，且依赖 JS 执行，无 JS 环境下失效。
为什么不能用 window.location.replace() 替代 href
window.location.replace() 会清除当前页面在 history 中的记录，用户点返回键直接回到上一级站点甚至浏览器首页，体验断裂。而 window.location.href = ... 至少保留一次可回退入口。
更关键的是：如果跳转目标页也 404，用 replace() 会让用户彻底卡死——连按返回都回不到原 404 页面排查问题。
复杂点在于：跳转逻辑必须区分「真 404」和「SPA 路由 404」。单页应用常把所有请求 fallback 到 index.html，此时服务端永远不返回 404，前端路由自己判断路径无效——那跳转就该由前端路由守卫（如 Vue Router 的 router.beforeEach）控制，而非 HTML 层面。
