404错误表示服务器已接收请求但无法找到指定资源。常见原因包括网址输入错误、文件未部署或路径错配、服务器重写规则不当，需通过核对url、检查文件存在性、审查服务器配置及使用network面板精准定位问题。
当你在浏览器地址栏输入网址后看到“404 Not Found”提示，说明服务器已成功接收请求，但无法在指定路径下定位到所请求的网页、图片、脚本或API端点——这不是网络断开或网站崩溃，而是资源确实缺失或路径错配。你不需要重启电脑、清DNS缓存或重装浏览器，只需按真实发生环节逐层排查。
第一步：确认是不是你自己输错了网址
这是占比超60%的触发原因，Linux服务器对大小写、斜杠、空格极其敏感，一个字符偏差就直接返回404。
复制地址栏中当前完整URL，粘贴进记事本里，逐字符比对原始链接是否一致——尤其注意/assets/和/Assets/、/blog/和/blog（末尾缺斜杠）、.html被误写成.htm等情况。
手动删除地址末尾所有内容，只保留到上一级目录（例如把https://site.com/products/detail?id=123简化为https://site.com/products/），回车访问，看能否打开目录页或导航入口。
检查是否混入了中文标点、全角空格或零宽字符——这些在地址栏里看不见，但会破坏路径解析。最稳妥的方式是：关掉当前标签页，重新手敲域名+斜杠，再从网站导航栏点击目标页面。
第二步：查资源到底在不在服务器上
如果网址没错，问题大概率出在文件没部署、路径改了或权限不对。
方法一：用FTP或cPanel文件管理器，进入网站根目录，按URL路径逐级展开，确认对应HTML文件、图片或JS文件真实存在。比如请求的是/js/main.js，就要去public/js/或www/js/下找main.js，而不是main.min.js或Main.js。
方法二：如果你有SSH权限，在终端执行：ls -l /var/www/html/path/to/file.css。如果返回No such file or directory，说明文件根本没上传或路径拼写错误；如果返回权限信息但文件大小为0，说明上传中断，需重新上传。
【关键提醒】构建工具（如Vite、Webpack）默认输出路径可能与实际部署路径不一致。例如Vite配置了base: '/admin/'，但你把产物直接扔进了网站根目录，所有src="/admin/assets/logo.png"就会全部404——必须按base值部署，或修改构建配置。
第三步：检查服务器路由与重写规则
静态文件存在、URL也正确，却仍404？那很可能是Nginx或Apache的配置挡住了请求。
① 打开网站根目录，开启“显示隐藏文件”，找到.htaccess（Apache）或nginx.conf（Nginx），搜索关键词404、deny、rewrite、try_files。
② Apache用户检查是否有这行：ErrorDocument 404 /404.html——它本身不导致404，但若/404.html不存在，会引发二级404；更危险的是RedirectMatch 404 ^/old-.*这类主动返回404的规则，需临时注释掉测试。
③ Nginx用户重点看location /块里的try_files指令。SPA应用常用try_files $uri $uri/ /index.html;，但如果漏了/index.html或写成/index.htm，所有子路由都会404。
④ 若网站启用了伪静态（如WordPress固定链接、Next.js SSR），需确认重写规则是否覆盖当前路径。例如location /api/ { proxy_pass https://backend/; }末尾少了个/，会导致/api/users被代理成https://backend//users（双斜杠），上游服务拒绝处理而返回404。
第四步：用开发者工具锁定具体哪一环失败
别猜，直接看浏览器Network面板——这是唯一能区分“真404”和“假404”的现场证据。
按F12打开开发者工具→切换到Network标签页→刷新页面→在Filter框输入404，只留失败请求。
点击任一404请求，看Headers里的Status是否真是404；再看Preview标签页：如果显示正常HTML内容，说明服务器错误地返回了200状态码（即“伪404”），必须修正服务端状态码设置；如果Preview为空或显示“Not Found”，才是真缺失。
看Initiator列：如果是HTML发起的，说明、或标签路径写错；如果是
fetch或XHR，说明前端JS调用的API地址不对，要去代码里改fetch('/v1/data')而不是靠修服务器解决。
