404 错误本质是浏览器请求的 URL 与真实文件路径不匹配；需通过 Network 面板查看实际 Request URL，结合当前页面 URL 和 href 路径写法（相对、绝对、根相对）精准比对，尤其注意 file:// 协议陷阱和 modulepreload/canonical 等静默失效场景。
404 不是文件丢了，而是浏览器发错了地址——先看 Network 里它到底请求了什么 URL，再比对真实文件位置。
打开 Network 面板确认真实请求路径
浏览器不读你的心，只按规则拼 URL。双击打开 HTML 或输错路径，它照样发请求，只是目标可能根本不存在。
- 按
F12打开开发者工具 → 切到Network标签页 → 刷新页面 - 找到标红的 404 请求（比如
style.css、img/logo.png或/api/user），点开看Request URL - 这个 URL 就是浏览器“以为”的资源地址，和你本地文件树无关，只跟当前页面 URL 有关
- 如果
Request URL是https://example.com/blog/css/style.css，但你的 CSS 其实放在项目根目录/css/style.css，那问题就出在href="css/style.css"这个相对路径上
区分三种路径写法的实际效果
同一段 href="css/style.css"，在不同页面 URL 下解析结果完全不同，不是“看着对就行”。
- 当前页面 URL 是
https://example.com/index.html→ 请求https://example.com/css/style.css - 当前页面 URL 是
https://example.com/blog/post.html→ 请求https://example.com/blog/css/style.css - 写成
href="/css/style.css"→ 一律请求https://example.com/css/style.css（从域名根开始） - 写成
href="./css/style.css"和href="css/style.css"效果相同，都基于当前页面路径；但../多一层就容易越界，比如在/blog/a/b.html里写../css/style.css才会回到/blog/css/
本地双击打开 HTML 时的特殊陷阱
file:// 协议下路径解析不可靠，很多相对路径根本不会发出请求，也不报错，直接静默失败。
立即学习“前端免费学习笔记（深入）”；
- 浏览器地址栏显示
file:///Users/name/project/index.html，但href="css/style.css"可能被拦截或忽略 -
rel="stylesheet"拼错（如rel=" styleSheet "带空格）、漏写、写成rel="css"，都会让标签退化为普通link，不发请求、Elements 里能看到、Styles 面板永远空 - 本地开发务必用服务启动：
python3 -m http.server 8000或vite preview，才能复现真实 HTTP 环境下的路径行为 -
type="text/css"已废弃，删掉更干净；rel必须严格小写、无空格、无拼写错误
modulepreload / canonical 的 href 错误最难发现
这两类 link 标签写错 href，Network 面板里压根看不到请求，也不报错，功能却完全失效。
-
<link rel="modulepreload" href="utils.js">如果utils.js路径不对，JS 不会预加载，但控制台没提示 -
<link rel="canonical" href="/article/123">写成href="article/123"，搜索引擎可能忽略该声明 - 它们不像
stylesheet那样有视觉反馈，必须手动检查 HTML 源码里的href值是否与实际部署结构一致 - 尤其注意构建工具（Vite、Webpack）输出路径和
base配置是否匹配，比如vite.config.ts中base: "/app/"，那所有相对 href 都要按这个前缀算
真正卡住人的往往不是“找不到文件”，而是“浏览器请求的路径和你以为的路径根本不是一回事”。Network 面板里的 Request URL 是唯一可信依据，其余全是猜测。每次改完路径，别急着刷新，先看那一行红字是不是变成了你想要的地址。
