直接看浏览器Network面板中Request URL字段，它就是路径错误的唯一真相：打开DevTools→Network→刷新页面→筛选css→找到标红404请求→点开查看Request URL，该URL即浏览器实际请求的最终地址，也是修复路径的唯一依据。
直接看浏览器 Network 面板里 Request URL 是什么，它就是路径错误的唯一真相——别猜、别试、别改文件名，先确认浏览器到底在找哪个地址。
怎么看实际请求的是哪条路径？
打开 DevTools → Network → 刷新页面 → 筛选 css → 找到标红的 404 请求 → 点开看 Request URL 字段。这个 URL 就是浏览器拼出来的最终地址，也是你修复路径的唯一依据。
-
file:///css/style.css：说明你在双击 HTML 文件运行，/指向磁盘根目录（如 C:/），不是项目根，必然 404 -
http://localhost:5173/pages/css/style.css：HTML 在/pages/下，但 CSS 实际在/css/，说明 href 写成了css/style.css（少了一个../） -
https://example.com/css/style.css返回 404，但文件实际在/static/css/style.css：绝对路径没对齐部署结构
href 里写 ./css/style.css 还是 css/style.css？
./ 是冗余的。浏览器解析相对路径时，默认起点就是当前 HTML 所在目录，./css/style.css 和 css/style.css 完全等价，但多写一个 ./ 增加出错概率（比如误写成 .\css\style.css，反斜杠在 HTML 中无效）。
- HTML 在
/src/index.html，CSS 在/src/css/style.css→ 写href="css/style.css" - HTML 在
/src/pages/a/b.html，CSS 在/src/css/style.css→ 写href="../../css/style.css" - 超过两次
../就该警觉：目录结构可能已失衡，要么扁平化，要么换构建工具接管路径
Vite/Webpack 项目里，/css/style.css 为什么上线就挂？
以 / 开头的路径是“站点根路径”，但它依赖服务器配置的 document root。本地用 Vite dev server 时，/ 指向 dist/；但部署到 Nginx，如果 root 指向的是 /var/www/myapp，而你没把构建产物放进去，照样 404。
立即学习“前端免费学习笔记（深入）”；
- 开发阶段优先设
base: "./"（Vite）或publicPath: "./"（Webpack），所有资源路径基于 HTML 当前位置解析，不依赖服务器根 - 必须部署到子路径（如
https://user.github.io/my-app/）？改base: "/my-app/"，HTML 中 href 仍保持css/style.css，由构建工具自动补全 - 别在 HTML 里混用
<base href="/xxx">和手写/css/路径——它会污染所有相对链接（<a>、<img>全受影响）
CSS 文件里的 url("../img/logo.png") 为啥单独报错？
<link> 的 href 路径和 CSS 内部的 url() 完全无关。前者以 HTML 为基准，后者永远以**最终生成的 CSS 文件位置**为基准——这是最常被忽略的独立路径系统。
- CSS 在
dist/css/app.css，图片在dist/img/logo.png→url("../img/logo.png")正确 - 但如果你把图片放在
src/assets/，又没配构建工具重写url()，那编译后路径就断了 - SCSS 中慎用
url('./logo.png')：Webpack/Vite 编译期按 SCSS 文件位置解析，但浏览器运行时按最终 CSS 位置解析，上下文不一致 - 更稳的法子：用 SCSS 变量 + 插值，比如
$img-logo: "/assets/logo.png"; background-image: url(#{$img-logo});，绕过自动路径解析
路径问题从来不是“写对就行”，而是“在哪个环节、以哪个文件为基准、被哪个工具解析”的三重校准。Network 面板里的 Request URL 是铁证，其余全是假设。
