结论：index.html 本身不处理404，真正决定是否返回404的是服务器或托管平台对请求路径的匹配逻辑；spa需通过fallback配置（如nginx的try_files、netlify的200重写）将未命中请求交由index.html处理，使前端路由接管，且必须排除api等真实接口路径。
直接说结论：index.html 本身不处理 404，它只是个静态文件；真正决定是否返回 404 的是服务器或托管平台对请求路径的匹配逻辑。所谓“index.html 处理 404”，其实是通过配置让服务器把所有未命中资源的请求都 fallback 到 index.html，由前端路由接管——这是 SPA 的核心机制，不是 HTML 文件自己在做重定向。
为什么刷新页面会 404？
浏览器访问 /about 时，如果没配 fallback，服务器会去磁盘找 ./about/index.html 或 ./about.html 这类真实文件。SPA 根本没生成这些文件，只生成了 index.html 和一堆 JS/CSS，所以服务器找不到就返回 404。
- 本地用
vite preview或http-server -s不出问题，是因为它们默认启用了 SPA fallback（-s就是--spa） - 但裸跑
http-server（无参数）、直接双击打开index.html、或 Nginx/Netlify 未配规则，都会触发真实 404 - 注意：这个 404 是服务器返回的 HTTP 状态码，不是前端 JS 抛的错误
Netlify 上必须用 netlify.toml 配 200 重写
Netlify 默认只对真实存在的文件返回 200，其余一律 404。要让它把所有路径都交还给前端路由，得强制重写，且必须用 status = 200（不是 301/302）：
[build] command = "vite build" publish = "dist" [[redirects]] from = "/*" to = "/index.html" status = 200
-
from = "/*"匹配所有路径，包括/、/user/123、/api/xxx（注意：如果你有真实 API，得在前面加一条排除规则） -
status = 200表示内部重写（rewrite），URL 不变，前端 JS 能读到原始路径；用301就变成跳转，破坏路由状态 - 别用
_redirects文件替代，它不支持status = 200的 rewrite 语义，只支持 redirect
Nginx 必须用 try_files，不能只靠 error_page
error_page 404 /index.html 是错的——它会让所有 404 都跳转到 /index.html，但 URL 变成 /index.html，前端路由拿不到原始路径，useHistory 直接失效。
- 正确做法是：
location / { try_files $uri $uri/ /index.html; } -
$uri先查真实文件（如logo.png）→ 存在就返回 -
$uri/再查目录（如/assets/）→ 存在就列目录或找index.html - 都失败才 fallback 到
/index.html，且 HTTP 状态仍是 200，URL 保持原样 - 别漏掉
root或alias配置，否则/index.html找不到文件
不要在 index.html 里写 meta refresh 或 JS 跳转来“修复”404
有人在 404.html 里写 <meta http-equiv="refresh" content="0;url=/">，这看似能跳回去，但本质是掩盖问题：
- 用户看到的是真实的 404 响应头（HTTP 404），SEO 友好性归零
- 跳转后 URL 变成
/，历史记录丢失，前进/后退失效 - 如果原始路径含 hash（如
#user）或 search（如?id=5），JS 跳转很难完整还原 - 真正的解决点永远在服务器/托管层配置，而不是让 HTML 自己抢救
最容易被忽略的一点：所有 fallback 配置都只对「前端路由路径」有效；如果你的 SPA 同时发真实 API 请求（比如 /api/users），必须确保这些路径不被 fallback 规则捕获，否则后端接口永远收不到请求——Nginx 要加 location ^~ /api/ { proxy_pass http://backend; }，Netlify 要在 [[redirects]] 前加一条 from = "/api/*" 排除规则。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
