浏览器实际请求的URL是Network面板中失败CSS请求的Request URL，它以HTML文件URL为基准解析href路径，CSS内url()则以最终CSS文件位置为基准，二者独立且需确保Content-Type为text/css。
浏览器实际请求的 URL 是什么
404 错误不是 CSS 写错了，而是浏览器根本没找到那个文件——它发了一个请求，服务器返回 404。关键不是“你写了什么路径”，而是“浏览器拼出来去请求的是哪个地址”。打开 DevTools → Network → 刷新页面 → 筛选 css，点开失败的请求，直接看 Request URL 这一项，那就是你要修正的目标。
常见 Request URL 示例：
-
https://example.com/blog/css/style.css（但你的 CSS 其实放在/public/css/style.css）→ HTML 在/blog/下，相对路径自动向上偏移 -
file:///css/style.css（双击 HTML 打开时）→/指向磁盘根目录，必然 404 -
https://example.com/css/style.css返回 404，但文件实际在/static/css/style.css→ 绝对路径没对齐部署结构
href 路径的计算基准是 HTML 文件位置，不是 CSS 文件位置
<link> 的 href 永远以当前 HTML 页面的 URL 为起点解析，和 PHP 模板文件在哪、CSS 源码在哪、项目根目录在哪全无关系。这是绝大多数路径错误的根源。
- HTML 在
/pages/a/b.html，CSS 在/css/style.css→ 正确写法是href="../../css/style.css" - HTML 在
/index.html，CSS 在/css/style.css→href="css/style.css"或href="/css/style.css"都行，但语义不同：/css/是站点根路径，css/是相对路径 - 用 PHP
include("header.php")，而header.php里写了href="style.css"→ 基准仍是最终渲染出的 HTML URL，不是header.php文件位置
构建后 CSS 里的 url() 为啥也 404
CSS 文件内部的 url("logo.png") 或 @import，解析基准是**最终生成的 CSS 文件所在位置**，和 <link> 完全无关。开发时可能正常，build 后 CSS 被抽离到 dist/css/app.css，图片却在 dist/img/，相对路径就断了。
立即学习“前端免费学习笔记（深入）”；
- Vite/Webpack 默认把
public/下的资源按原路径输出，src/assets/下的会哈希重命名并调整路径 ——href必须匹配构建后的实际路径，不是源码路径 - 如果用了
@import "vars.css"，且vars.css和主 CSS 不在同一目录，构建后路径错位概率极高 - Webpack 的
publicPath或 Vite 的base配置不一致，会导致所有url()相对引用失效
rel="stylesheet" 缺失或拼错就等于没写
浏览器只靠 rel 值决定是否启动 CSS 解析流程。rel="stylesheet" 是唯一被 HTML5 规范认可的标识。漏掉、写成 rel="style"、rel="StyleSheet"（大小写敏感），甚至属性值带空格如 rel= "stylesheet"，标签就退化为普通链接：Network 面板能看到 200，但 Elements 面板 Styles 栏为空，控制台也不报错——静默失效。
- 检查
<link>是否完整包含rel="stylesheet"，且没有多余空格或全角字符 - 确认
<link>是<head>的直接子元素，别嵌套在<script>或<meta>里 - 别用 JS 动态插入
<link>来“优化首屏”，那只是把 FOUC 变成可预期的闪屏
真正麻烦的不是路径本身，而是路径基准在不同环节（HTML 引入、CSS 内部引用、构建工具输出）各自独立又容易混淆。每次改路径前，先看 Network 里的 Request URL，再对照文件实际部署位置，比凭感觉改更可靠。
