background-image: url() 的路径基准点是 css 文件所在目录，而非 html 页面或项目根目录；浏览器将 url() 内路径直接拼接在 css 文件 url 后，如 css 在 /static/css/app.css，则 url(images/bg.jpg) 会请求 /static/css/images/bg.jpg。
图片不显示，90% 是 url() 路径写错了——它永远以 CSS 文件所在目录为起点，不是 HTML 页面，也不是你“觉得”该在的位置。
background-image: url() 的路径基准点在哪？
浏览器拼接背景图 URL 时，是把 url() 里的字符串直接接在 CSS 文件的完整 URL 后面。比如 CSS 文件地址是 https://example.com/static/css/app.css，你写了 url(images/bg.jpg)，浏览器就真去请求 https://example.com/static/css/images/bg.jpg。
- 若图片实际在
/static/images/bg.jpg，就得写url(../images/bg.jpg) - 若用绝对路径，统一从站点根目录算起：
url(/images/bg.jpg)（开头必须有/） -
url(./images/bg.jpg)和url(images/bg.jpg)在多数场景效果一样，但./是冗余写法，没必要加 - 千万别写
url(C:/project/images/bg.jpg)或file:///开头的本地路径，现代浏览器会拒绝加载
相对路径 vs 绝对路径，怎么选？
相对路径灵活，但移动 CSS 文件后所有 url() 都得重调；绝对路径稳定，但耦合部署结构——比如你把项目部署到子路径 /myapp/，url(/images/bg.jpg) 就会变成请求 https://example.com/images/bg.jpg，而不是 https://example.com/myapp/images/bg.jpg。
- 开发阶段用相对路径更可控，尤其配合 Vite/Webpack 时，构建工具能自动解析并重写路径
- 静态资源放在
public/目录下（如 Vite），就用绝对路径：url(/bg.jpg) - Django 项目里，如果图片在
STATIC_ROOT下且通过STATIC_URL服务，也推荐url(/static/images/bg.jpg)（前提是STATIC_URL = '/static/'） - 避免
url(../public/bg.jpg)这类跨出项目根目录的写法，Webpack/Vite 通常直接报错
中文、空格、特殊字符导致图片加载失败怎么办？
直接写 url(我的背景.jpg) 在本地 file:// 协议或某些 Nginx 配置下会 404，因为未编码的中文和空格无法被一致解析。
- 最省事：改名，用英文+短横线，比如
hero-banner.jpg - 必须保留中文？手动 UTF-8 编码再百分号编码，例如 “背景图.jpg” →
%E8%83%8C%E6%99%AF%E5%9B%BE.jpg，但极易出错 - 路径含空格时，
url("my bg.jpg")比url(my bg.jpg)更稳妥，引号能防止解析截断 - 别在路径里用
#、?、(、)，除非明确编码成%23、%3F等
为什么 Network 里看到 404，但路径看起来没错？
打开浏览器开发者工具的 Network 标签页，点击那个失败的图片请求，看「Request URL」栏——那里显示的是浏览器真正发起的请求地址，一眼就能暴露问题。
- 路径多了一级目录？比如 CSS 在
/css/main.css，却写了url(../../images/bg.jpg) - 构建工具（如 Webpack）把图片输出到了
/assets/bg.abc123.png，但你写的还是原始文件名，没启用 asset 处理规则 - Vite 中用了
url(@/assets/bg.jpg)，但没配别名或resolve.alias，Vite 不认识@ - 图片确实存在，但服务器返回 403（权限）或 MIME 类型错误（比如 Nginx 没配
image/jpeg）
真正卡住人的，从来不是语法，而是搞不清那个“基准点”到底在哪。盯住 CSS 文件的实际位置，比背十遍规则都管用。路径一动，整个 url() 就得重算——这点在重构或迁移时最容易被忽略。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
