CSS中url()的路径基准永远是CSS文件自身位置，与HTML文件位置无关；@import同理，但存在串行加载和路径易错问题；推荐使用构建工具自动处理路径，避免手动拼写相对路径。
CSS里url()的路径基准永远是CSS文件自身位置
很多人以为 CSS 中 url(../img/logo.png) 的路径是从 HTML 文件算起的，其实完全不是。浏览器解析 CSS 内部的 url() 时，起点永远是该 CSS 文件所在的目录，和 HTML 在哪毫无关系。
比如：index.html 在 /src/pages/，style.css 在 /src/css/，那么 style.css 里写 url(../img/logo.png)，实际请求的是 /src/img/logo.png；如果写成 url(img/logo.png)，就去找 /src/css/img/logo.png。
常见错误现象：
- 本地双击打开 HTML 时图片显示空白，Network 面板看到请求的是
file:///img/logo.png（因为 CSS 被当作根目录加载） - 部署到子路径如
https://site.com/app/后，url(../img/...)指向了上层无关目录
@import 也遵循相同路径规则，但别在 CSS 里嵌套多层
@import 和 url() 一样，路径基准是当前 CSS 文件位置，不是 HTML。但它有个致命问题：串行加载——必须等当前 CSS 下载解析完，才发起 @import 的请求，容易拖慢渲染。
立即学习“前端免费学习笔记（深入）”；
更麻烦的是，如果 a.css 里 @import "b.css"，而 b.css 又 @import "c.css"，每层都要重新计算相对路径，极易出错。
实操建议：
- 避免在生产 CSS 中用
@import引入跨目录资源，尤其不要超过一层 - 开发阶段用 Sass/Less 是可以的，但构建时应展开为单文件或转成
<link> - 真要用，优先写绝对路径，比如
@import "/assets/vars.css"，前提是构建工具已配好 public 目录映射
构建工具能帮你绕过手写路径的坑
手写 ../ 或 ../../ 超过两次，基本说明目录结构或引用方式有问题。Vite、Webpack 这类工具能自动处理路径，比人靠谱得多。
例如 Vite 中，把图片放进 src/assets/，然后在 CSS 里直接写：
background-image: url('@/assets/logo.png');
这个 @/ 是 Vite 默认别名，指向 src/，打包时会自动替换成正确路径并哈希命名。
关键点：
- 别在 HTML 的
<style>块里写@import——现代浏览器会延迟加载，样式可能闪一下 - Webpack 需配
css-loader+resolve.alias才支持别名；Vite 默认支持@/和$/ - 如果用
public/目录放静态资源，CSS 里就得写url('/logo.png')，此时路径从域名根开始，和构建输出无关
本地预览和上线环境不一致？先看协议和服务器配置
file:// 协议下，/assets/logo.png 会被解析成磁盘根目录（比如 C:/assets/logo.png），肯定 404；只有 HTTP 服务（如 Vite dev server、Nginx）才把 / 当作站点根。
所以：
- 开发时别依赖
/xxx路径本地双击打开，一律用 Live Server 或vite preview - 部署到子路径（如 GitHub Pages 的
https://user.github.io/my-app/），Vite 要设base: "/my-app/"，否则url(/assets/...)会请求错地址 - CSS 文件内部的
url()不受 HTML 里<base>标签影响，这点特别容易被忽略
最稳的做法：所有资源都走构建工具处理，别手动拼路径。一旦开始数 ../ 的个数，就已经在给自己埋雷了。
