先确认端口是否被占用，再排查路径映射、代理配置及插件干扰；404常因端口冲突导致服务未真正启动，或静态资源路径与服务器根目录不匹配，亦可能由浏览器/vscode插件篡改请求所致。
VSCode本地启动项目时资源404，先确认是不是端口被占了
很多情况下你看到 Failed to load resource: the server responded with a status of 404 (Not Found)，其实根本不是路径或代码问题，而是开发服务器压根没真正跑起来——端口被其他进程占用了，VSCode悄悄 fallback 到了一个空服务或代理页，结果所有静态资源都 404。
快速验证：在终端运行 netstat -ano | findstr "9803"（把 9803 换成你项目实际用的端口），如果返回一行带 PID 的记录，说明端口确实被占。这时候别急着改代码，先干掉它：
- 记下输出末尾的数字（比如
5528） - 执行
taskkill /F /pid 5528 - 重启 VSCode 终端，再
npm run dev或对应命令
注意：Windows 下有时 netstat 在非 system32 目录下找不到，可先 cd c:\WINDOWS\system32\ 再执行。
静态资源 404 多半是路径映射没对上
VSCode 本身不提供 Web 服务，真正起作用的是你项目里用的工具（Vite、Webpack Dev Server、Vue CLI 等）。它们默认 serve 的根路径是项目根目录，但如果你在 HTML 里写了 <script src="/js/app.js"></script>，而实际文件在 src/assets/js/app.js，浏览器就会去请求 http://localhost:3000/js/app.js —— 这个路径服务器根本没配，自然 404。
常见错因：
-
public/目录下的文件才被直接映射到根路径，比如public/js/app.js→ 可通过/js/app.js访问 -
src/下的资源必须经构建处理，不能直接用绝对路径引用 - Vite 项目若配置了
base: '/myapp/'，所有资源路径会自动加前缀，import './main.js'最终解析为/myapp/main.js - Linux/macOS 部署时大小写敏感，
logo.PNG和logo.png是两个文件
浏览器插件和 VSCode 插件可能偷偷改请求
有些插件会在页面加载时注入脚本或重写资源 URL，尤其 Vetur（Vue）、ESLint、某些“前端助手”类插件，或浏览器里的油猴（Tampermonkey）、广告屏蔽器，都可能干扰 fetch 或 <link> 行为。
临时排除法：
- VSCode 里禁用 Vetur、Auto Rename Tag、Prettier 等非必要插件，重启窗口
- Chrome 打开隐身窗口（无扩展），访问同一地址
- 检查 Network 面板里 404 请求的 Initiator 列，如果是某个 js 文件名（比如
content-script.js），基本就是插件干的
API 接口 404 不等于前端代码写错了
如果控制台报的是 fetch("/dev-api/user") 或 axios.get("/api/list") 404，重点不在 JS 文件加载，而在请求是否真发到了后端。常见情况：
- 代理配置失效：Vite 的
server.proxy或 Vue CLI 的vue.config.js里 proxy 规则没生效，导致请求发到了前端服务自身（返回 index.html 或 404） - 环境变量错配：.env.development 里写了
VUE_APP_BASE_API=/dev-api，但后端实际接口是/api，且未部署反向代理 - 跨域被拦截后静默失败：某些代理配置错误会导致 OPTIONS 预检通过但 GET 仍 404，看 Network 里是否只有预检请求没主请求
最简单的验证方式：把报错的完整 URL（比如 http://localhost:3000/dev-api/user）粘贴到浏览器地址栏直接访问，看是返回 JSON 还是 404 页面——如果是后者，说明代理根本没转过去。
真实调试中，404 往往不是单一原因，而是端口、路径、代理、插件四层叠加出的问题。每次只动一个变量，用 Network 面板盯住那个红色 404 请求的 URL 和 Initiator，比翻文档更快定位。
