HTML文件本身不处理404，真正决定是否返回404的是服务器或托管平台对请求路径的匹配逻辑；SPA需通过fallback配置（如Nginx的try_files、Netlify的200重写）将未命中请求交由index.html处理，使前端路由接管，且必须排除API等真实接口路径。
HTML 文件本身不能重定向 404 错误页面——404.html 只是被服务器返回的静态内容，真正的重定向或状态码控制必须由服务器（Apache/Nginx）、托管平台（Netlify/GitHub Pages）或后端逻辑完成。前端 JS 在 404.html 里跳转，只会掩盖问题，让搜索引擎看到的是 200 OK + 错误路径，即“软 404”，SEO 危险。
为什么不能用 JavaScript 在 404.html 里做 window.location 跳转
用户访问 /nonexistent，服务器返回 404 Not Found 状态码 + 404.html 内容；如果你在该 HTML 里写：window.location.href = "/search?q=" + encodeURIComponent(location.pathname)，会发生：
- 浏览器地址栏短暂显示
/nonexistent，再跳到/search—— 用户感知割裂 - 响应头仍是
HTTP/1.1 404 Not Found，但 HTML 已被 JS 替换，爬虫可能抓取不到原始错误上下文 - 更严重的是：Google 明确将此类行为归类为软 404，不计入真实错误统计，且可能降权
- 移动端或禁用 JS 的环境直接卡死在空白或残缺页
真正有效的 404 处理必须由服务器层配置
关键不是“HTML 怎么重定向”，而是“服务器怎么把 404 请求交给你想要的页面，并保持正确状态码”。不同环境做法差异很大：
-
Apache：用
ErrorDocument 404 /404.html，路径必须以/开头；确保404.html文件 ≥512 字节，且上传到网站根目录 -
Nginx：不要用
error_page 404 /404.html简单配置——它默认不改状态码；正确方式是在location = /404.html块中加internal;，并在主 location 中用error_page 404 = /404.html;（注意末尾=表示状态码透传） -
Netlify：不支持自定义 404 状态码响应，但可通过
netlify.toml的[[redirects]]实现 fallback；若要真 404，只能靠构建时生成真实404.html并依赖平台默认行为 -
GitHub Pages：只认根目录下的
404.html，且仅当请求路径完全不匹配任何文件时才触发；无法返回带参数的跳转，也不能改状态码
SPA 场景下 index.html 的“假 404”本质
你刷 /about 出现 404，不是 HTML 的问题，是服务器没找到 /about/index.html 或 /about.html。此时应配 fallback，而非让 index.html “处理” 404：
立即学习“前端免费学习笔记（深入）”；
- Nginx 正确写法：
location / { try_files $uri $uri/ /index.html; }—— 所有未命中路径都内部 rewrite 到/index.html，状态码仍是200 - Netlify 必须用
status = 200的重写规则，status = 404不被支持 - GitHub Pages 没有原生 fallback，只能靠
404.html里的 JS 解析location.pathname，再用history.replaceState+router.push模拟，但首次加载仍是 404 状态
最容易被忽略的一点：无论你用什么方案，都要用 curl -I 验证响应头——看到 HTTP/1.1 404 Not Found 才算真实 404；如果返回 200 或 302，那根本不是错误处理，是掩盖或误配。
