先看Network面板中失败请求的Request URL，再核对服务器真实路径、大小写、扩展名及Web根目录配置，最后排查重写规则和默认索引设置。
检查浏览器 Network 面板里的真实请求路径
看到 404 不要急着改代码，先打开 F12 → Network → 刷新页面，找到标红的那条请求，点开看它的 Request URL。这个地址才是服务器真正收到的路径，比你猜的更可靠。
- 如果
Request URL是http://localhost/js/app.js，但你实际文件在./assets/js/app.js，那就说明src或href写少了assets/ - 如果 URL 末尾多了一个
.html.html或带了不可见空格（比如%C2%A0），就是复制粘贴时混入了全角字符或富文本残留 - 注意
Status列是否真为404：有时前端路由跳转失败、fetch报错或iframe加载失败也会被误读为 404，得看状态码而不是控制台文字
验证文件是否真的在服务器对应位置
别只看本地文件夹结构，要进服务器环境确认物理路径和权限。Linux 和 Windows 对大小写、扩展名的处理逻辑不同，部署后常在这里翻车。
- 用
ls -l /var/www/html/assets/img/logo.png（Linux）或资源管理器直接导航（Windows）核对文件是否存在，注意Logo.png≠logo.png - 检查文件扩展名是否被系统隐藏：Windows 下容易存成
index.html.txt，需开启“文件扩展名”才看得见 - 确认 Web 服务器的根目录配置：Apache 的
DocumentRoot、Nginx 的root、Vite 的base都必须和你写的相对路径起点一致
修正 HTML 中的 src/href 路径写法
路径不是越短越好，也不是越长越稳，关键看它相对于当前 HTML 文件的解析上下文是否成立。尤其要注意 iframe、img、script 这三类标签最容易因路径偏差报 404。
- 避免用
../往上跨太多级：比如pages/blog/post.html里写<img src="../../assets/logo.png">，一旦移动文件位置就失效；改用根相对路径/assets/logo.png更可控 -
iframe的src在 Jenkins/Jetty 等服务下不认../，必须写完整协议+域名，或至少以/开头的绝对路径 - 动态拼接路径时（如
<img src="${path}/icon.svg">），确保path变量值不为空、不带重复斜杠（//icon.svg）、不漏开头/
排查服务器重写规则和默认索引设置
很多 404 其实不是文件丢了，而是请求根本没走到目标文件——被 .htaccess 或 nginx.conf 拦截、改道、或静默返回了错误页面。
立即学习“前端免费学习笔记（深入）”；
- 临时重命名
.htaccess为.htaccess.bak，刷新测试：如果 404 消失，说明某条RewriteRule匹配异常 - 检查 Nginx 的
try_files是否漏掉/index.html，SPA 应用常见问题：try_files $uri $uri/ =404应改为try_files $uri $uri/ /index.html - 确认 Apache 的
DirectoryIndex包含你要的入口文件，比如DirectoryIndex index.html default.html，否则访问/blog/会 404 而不是自动找index.html
最易被忽略的一点：404 响应本身是否返回了正确的 HTTP 状态码？有些自定义错误页被配置成返回 200，搜索引擎会当真页面收录，导致大量死链堆积。用 curl -I http://localhost/missing.html 看响应头里的 HTTP/1.1 404 Not Found 才算到位。
