浏览器解析CSS路径以页面URL为基准而非文件物理位置，相对路径易因路由错位失效，绝对路径（/开头）更可靠但需服务器正确映射静态资源。
CSS 文件路径看着没错，但浏览器控制台仍报 404 或样式不生效，大概率是路径解析基准点被误判了——它永远以用户访问的页面 URL 为准，不是你编辑的 HTML 文件位置，也不是 PHP 模板所在目录。
浏览器请求 URL 才是路径计算的唯一基准
比如你在 http://localhost:3000/blog/article/ 打开页面，HTML 中写 href="css/style.css"，浏览器就会去请求 http://localhost:3000/blog/article/css/style.css，而不是项目根目录下的 /css/style.css。即使你的 HTML 文件物理上在项目根目录，只要它被路由（如 Flask、Next.js、WordPress）动态生成并返回给这个 URL，路径就按这个 URL 解析。
常见误操作：
- 在 WordPress 的
header.php里写../css/style.css，指望它回退到主题根目录——没用，浏览器根本不看 PHP 文件在哪 - 本地双击打开
index.html（file://协议），然后用../css/style.css引入——现代浏览器会直接拒绝跨目录加载，报net::ERR_FAILED - 开发时用 Python 的
python3 -m http.server启服务，却把 CSS 放在./assets/css/，而 HTML 中写href="assets/css/style.css"——服务默认只暴露当前目录，assets必须真实存在且可读
<link> 中该用相对路径还是绝对路径？
相对路径（如 css/style.css）只在「HTML 文件和请求 URL 完全对齐」时才可靠，比如静态站点所有 HTML 都放在根目录、直接通过 http://site.com/index.html 访问。绝大多数动态或路由项目不适合。
立即学习“前端免费学习笔记（深入）”；
绝对路径（以 / 开头）才是线上和开发环境的通用解法：
-
href="/css/style.css"→ 请求http://site.com/css/style.css，与当前页面 URL 无关 - 必须确保 Web 服务器实际能响应这个路径：Nginx 要配
location /css/ { alias /var/www/static/css/; }，Flask 要设static_url_path='/css'并把文件放对位置 - 在 PHP 环境（如 WordPress）中，优先用函数生成路径：
href="<?php echo get_template_directory_uri(); ?>/css/style.css"，避免硬编码
@import 在 CSS 文件里为什么突然 404？
CSS 内部的 @import 规则，路径基准点不是 HTML 页面，而是「当前 CSS 文件自身的位置」。这和 <link> 完全不同。
典型陷阱：
- 主 CSS
/static/css/main.css里写@import "vars.css"→ 浏览器去找/static/css/vars.css - 但如果你用构建工具（Vite/Webpack）把
main.css输出到了/dist/css/，而vars.css还在源码/src/styles/，构建后路径就断了 - Vite 默认不支持
@import "@/styles/vars.css"，除非你在vite.config.js显式配置resolve.alias
建议：少用 @import 做模块拆分，改用构建入口聚合（如 main.css 统一 @import 所有子模块），或直接用 JS 动态导入 CSS。
调试时最容易被忽略的三件事
路径写对了，服务器也配好了，还是加载失败？盯紧这三点：
- 浏览器 DevTools 的
Network标签页里，点击那个 404 的 CSS 请求，看Preview或Response——有时服务器返回的是 200，但内容是 Nginx 的 404 页面 HTML，说明静态路由根本没命中 - 检查文件权限和大小写：Linux 服务器上
Style.css≠style.css，FTP 上传时可能自动改名 - 强制刷新（Ctrl+F5）或禁用缓存（DevTools → Network → ✅ Disable cache）——旧缓存可能掩盖路径修正效果
真正卡住人的，往往不是“怎么写”，而是“从哪算起”这个隐含前提没被验证过。每次改完路径，先看 Network 里请求地址是不是你预期的那个 URL，比反复检查代码更省时间。
