CSS 中 url() 的路径解析基准是 CSS 文件自身位置，而非 HTML 页面或浏览器地址栏；@import 路径同理，但应避免用 url() 包裹；构建工具会重写路径，需确保配置正确。
检查 CSS 文件与目标资源的相对位置关系
CSS 里的 url() 是相对于 CSS 文件自身所在路径解析的，不是 HTML 页面路径，也不是当前浏览器地址栏路径。很多人误以为写在 index.html 里引入的 CSS，其内部路径就该以 HTML 为基准，结果引入图片、字体或背景图时 404。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 打开开发者工具 → Network 标签页，看报错的资源请求地址（比如
http://localhost:3000/css/images/icon.png），对比你期望的真实路径，反推 CSS 文件到底“认为自己在哪” - 用文件管理器展开目录，确认 CSS 文件物理位置，再数清楚要“向上退几层”（
../）、“向下进几个文件夹”（img/logo.svg） - 如果 CSS 被内联在 HTML 中（
），那url()才以 HTML 所在路径为基准——但这种写法本身就不利于复用和缓存
避免使用绝对路径却误写成根相对路径
以 / 开头的路径（如 url(/assets/logo.png)）是根相对路径，从域名后第一级开始算，不是“项目根目录”。本地用 file:// 协议打开 HTML 时，/ 指向磁盘根（如 C:/），必然失败；用本地服务器（如 python -m http.server）时，/ 指向服务启动目录，也未必是你想要的“项目根”。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 开发阶段优先用纯相对路径（不含
/），只靠../和子目录名组合 - 上线前若需统一前缀，用构建工具（如 Webpack 的
public目录或assetPrefix）处理，而不是手写/static/ - 浏览器地址栏显示
http://localhost:8080/sub/page.html，不代表/assets/就一定存在——它取决于服务器如何配置静态资源映射
注意 CSS @import 和 url() 对路径的处理差异
@import 语句中的路径，同样以当前 CSS 文件为基准，但它还有额外限制：如果写成 @import "base.css"，浏览器会尝试加载同目录下的 base.css；但如果写成 @import url("base.css")，部分旧版浏览器可能错误地以 HTML 为基准解析——虽然现代浏览器已统一，但混用容易引发困惑。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 统一用
@import "path/to/file.css";（不带url()包裹），语义清晰且兼容性好 - 避免在被
@import的子 CSS 里再用大量../回溯，路径嵌套越深越难维护 - 如果子 CSS 依赖其他资源（如字体），它的
url()仍以自身位置为准，不是父 CSS 的位置
构建工具导致路径重写时的常见陷阱
Vite、Webpack 等工具默认会对 CSS 中的 url() 进行重写：把 url(./img.png) 编译成 url(/assets/img.abc123.png)。这本是优化，但如果你手动写了带哈希的路径、或用了别名（如 @/assets），而工具没配置别名解析，就会找不到文件。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 检查构建配置中是否启用了
assetsInclude（Vite）或url-loader/asset-module（Webpack），确保目标文件类型被纳入处理范围 - 在 CSS 中避免使用构建工具不识别的别名写法，例如不要写
url(@/images/bg.jpg)，改用相对路径url(../images/bg.jpg) - 开发时开启构建工具的
build.report或查看dist目录输出，确认最终生成的 CSS 里路径是否符合预期
最常被忽略的一点：CSS 路径问题往往不是“写错了”，而是你没意识到路径解析的基准是谁。打开控制台看 Network 请求的实际 URL，比反复猜 ../ 个数更可靠。
