404页面必须返回真实HTTP 404状态码，否则搜索引擎误判、用户无重试提示；本地file://协议无状态码，须用HTTP服务验证；Nginx需防location覆盖、try_files吞掉404、权限或配置未重载；静态平台严格限定文件名、路径及配置方式；404.html须内联CSS、禁JS、用绝对路径、直写“404”文本并加noindex。
404页面不是“放个404.html就能用”，它必须返回真实的404 Not Found状态码，否则搜索引擎当它是普通页，用户刷新也得不到重试提示。
为什么本地双击打开404.html永远不生效
浏览器通过file://协议加载文件时，根本不存在HTTP状态码——所以你看到的“404页面”只是个普通HTML，和服务器无关。验证必须走HTTP服务：
- 用
npx serve、python3 -m http.server 8000或php -S localhost:8000起本地服务 - 访问
http://localhost:8000/nonexistent-path - 打开DevTools → Network → 刷新 → 看响应头第一行是否为
HTTP/1.1 404 Not Found - 命令行验证：
curl -I http://localhost:8000/nonexistent，输出首行必须含404
Nginx配置error_page后仍返回200的常见原因
配了error_page 404 /404.html;却还是200，大概率是被其他location规则覆盖或拦截了：
- 漏写
location = /404.html { internal; }：没加internal，外部可直连/404.html，Nginx会把它当普通请求处理，返回200 -
try_files $uri $uri/ /index.html;在location /里：SPA常用写法，但它会把所有未命中路径都fallback到index.html，真实404被吞掉 -
/404.html路径下文件实际不存在，或权限不足（如Nginx用户无法读取） - 配置没重载：
sudo nginx -t && sudo systemctl reload nginx缺一不可
静态托管平台（GitHub Pages / Vercel / Netlify）的硬性约定
这些平台不跑完整Web服务器，自定义404必须严格按规则来，错一个字符就失效：
立即学习“前端免费学习笔记（深入）”；
- 文件名必须是
404.html（全小写、无空格、无BOM），且放在仓库或项目**根目录**；pages/404.html、error/404.html、404.htm全都不认 - GitHub Pages：只识别根目录
404.html，不执行JS，不支持重定向规则 - Vercel：需在
vercel.json中显式配置"rewrites"并设"status": 404，不能只靠文件名 - Netlify：必须用
_redirects文件写/* /404.html 404，或netlify.toml中配[[redirects]] - Git提交检查：
git ls-files | grep 404确认文件真被跟踪，Windows记事本保存可能带BOM导致失败
404.html文件本身容易被忽略的限制
它不是普通网页，而是在HTTP 404状态下被服务器注入响应体的内容，很多“合理操作”在这里会翻车：
- CSS必须内联在
<style></style>里：外部<link rel="stylesheet">在CDN故障、GitHub Pages或某些Nginx配置下极大概率加载失败，导致白屏 - 禁用JavaScript核心导航：比如用
history.back()或fetch()加载推荐内容——Cloudflare免费版、GitHub Pages默认不执行JS - 所有资源路径必须用绝对根路径：
/img/logo.svg，不能用./logo.svg或img/logo.svg，否则不同URL深度下路径解析失败，又触发一次404 -
<h1></h1>必须直写“404”字样（如<h1>404 Not Found</h1>），不能用图片、SVG文本或JS动态插入，否则SEO和屏幕阅读器无法识别 - 加
<meta name="robots" content="noindex">，防被搜索引擎误收录为普通页面
最常被绕开的点是：状态码必须由服务端发出，前端任何跳转、history.replaceState或<meta http-equiv="refresh">都只能返回200——这意味着你花三小时做的动画和交互，对爬虫和部分用户来说根本不存在。
