二级页面404本质是服务器找不到请求的物理文件，需先登录服务器或FTP按URL路径逐级核对文件是否存在，排查上传遗漏、路径错误、扩展名隐藏、中文空格、权限问题及Web服务器路由配置是否正确。
确认二级页面文件是否真在服务器对应路径下
404 的本质是“服务器找不到你请求的文件”，不是前端报错也不是 JS 崩溃。先别改代码，直接登录服务器或 FTP，按浏览器地址栏里的完整路径一级级打开目录，看 about.html、contact/index.html 这类二级页面是否真实存在于 public/ 或 htdocs/ 对应子目录中。
常见漏点：
- 文件上传时被跳过（比如 IDE 同步忽略
.html后缀，或 Git 未提交） - 本地开发用的是
src/pages/contact.html，但构建后输出到dist/contact.html，而你访问的是/pages/contact.html - 路径含中文或空格，如
/产品介绍.html，服务器默认不支持或需 URL 编码 - Windows 下文件扩展名被隐藏，实际是
contact.html.txt，但显示为contact.html
检查 Web 服务器是否把请求正确路由到二级路径
静态服务器（如 Nginx、Apache、Vercel、GitHub Pages）对根目录和子目录的处理逻辑不同。例如你访问 https://example.com/blog/post-1.html，服务器必须能从 /blog/post-1.html 这个物理路径读取文件，而不是只认 /index.html。
实操要点：
立即学习“前端免费学习笔记（深入）”；
- Nginx：确认
location /块里没加try_files $uri =404却漏了$uri/，否则/blog/这类目录请求会直接 404，而不是尝试找/blog/index.html - Apache：
.htaccess中若用了重写，检查RewriteRule是否拦截了所有子路径却没 fallback；临时重命名.htaccess测试是否恢复 - 前端路由项目（Vue Router / React Router）：二级页面是前端渲染的，但首次加载仍需服务端返回
index.html。确认 Nginx 的try_files $uri $uri/ /index.html;已配置，且没被其他 location 覆盖 - GitHub Pages：只支持根目录下
404.html，二级路径如/admin/必须真实存在该目录及其中的index.html，不能靠前端路由兜底
验证浏览器请求的真实路径与响应状态码
你以为你在访问 /products/widget.html，但 Network 面板可能显示它实际发起了 /products/widget.html?_t=123 或被重定向到了 /404.html。不看 Network，纯靠肉眼判断等于蒙眼修车。
操作步骤：
- F12 → Network → 刷新页面 → 找到触发 404 的那个请求（Status 列标红）
- 点开它 → Headers → 看 Request URL 是否和你预期一致；Response Headers → 确认 Status 是
404 Not Found，不是200 OK（后者是软 404，更难排查） - 右键该请求 → “Copy → Copy request URL”，粘贴进新标签页直访，排除 JS 重定向干扰
- 用
curl -I http://localhost:8080/products/widget.html看原始响应头，绕过浏览器缓存
检查 HTML 内部链接是否用相对路径导致跳转错位
一个常见陷阱：你在 index.html 里写 <a href="about.html">，点击正常；但当你在 /blog/2024.html 页面里也写同样链接，浏览器会拼成 /blog/about.html，而非根目录下的 /about.html。
修复方式很简单，但极易被忽略：
- 所有跨目录跳转统一用绝对路径：
<a href="/about.html">（开头带/） - 避免
../about.html这类相对路径，尤其当页面结构未来可能调整时 - 检查
<base href="/>标签是否误设，它会全局改变所有相对 URL 解析基准 - 构建工具（如 Vite、Webpack）若启用了
base配置，确保其值与部署路径一致，否则生成的href和src全部偏移
