background-image 的 url 路径始终相对于 css 文件所在目录，而非 html 文件；绝对路径从域名根开始；需避免未编码的中文、空格及特殊字符，推荐英文命名或构建工具自动处理；svg 作背景时 data url 更可靠。
background-image 的 URL 路径是相对 CSS 文件位置的
很多人以为 background-image: url(...) 里的路径是相对于 HTML 文件的，结果图片死活不显示。不是的——它永远以当前 CSS 文件所在目录为基准解析路径。
比如 CSS 文件在 /static/css/main.css，里面写 url(../images/bg.png)，浏览器就会去请求 /static/images/bg.png；如果写成 url(images/bg.png)，就找 /static/css/images/bg.png。
- 绝对路径（如
/assets/bg.jpg）从域名根开始，最稳但耦合部署结构 - 相对路径更灵活，但移动 CSS 文件时必须同步检查所有
url() - 不要用
file://或本地绝对路径（如C:/.../bg.png），浏览器会拒绝加载
URL 中的空格、中文、特殊字符必须编码或避免
直接写 url(背景图.jpg) 在多数浏览器里会失败，因为未编码的中文或空格会被截断或转义错误。HTTP 规范要求路径中的非 ASCII 字符必须用 UTF-8 编码再百分号编码。
实际做法不是手动编码，而是：改文件名——用英文+下划线/短横线，比如 hero-banner.jpg；或者确保构建工具（如 Webpack、Vite）已配置 asset 处理规则，自动重命名并注入正确路径。
立即学习“前端免费学习笔记（深入）”；
- 常见报错：
Failed to load resource: the server responded with a status of 404 ()，但路径看起来“没错”——大概率是编码问题 - Chrome 开发者工具的 Network 标签页里点开那个 404 请求，看「Request URL」栏的真实地址，一眼就能发现空格变为了
%20或直接被截断 - URL 里不要出现
#、?、括号等，除非你明确做了编码（%23、%3F等）
使用 CSS 预处理器（如 Sass）时，@import 不影响 background-image 路径解析
Sass 的 @import 或 PostCSS 的 @import 只是内容拼接，不会改变路径解析上下文。也就是说，即使你在 _mixins.scss 里写了 background-image: url(../img/icon.svg)，最终生成的 CSS 仍按引用该 _mixins.scss 的主 CSS 文件位置算起。
真正影响路径的是「最终输出的 .css 文件在哪」，不是源文件在哪。所以如果你用 Sass 编译到 dist/css/app.css，那所有 url() 都以 dist/css/ 为基准。
- 别依赖
@import把路径“带进去”——它不带路径上下文 - Vite 和 Webpack 5+ 的
url()会自动解析为 base64 或 public 目录资源，但前提是路径能被解析器识别（比如不能跨出项目根） - 用
~前缀（如url(~@/assets/bg.png)）只在特定 loader 下有效，不是 CSS 标准，纯 CSS 文件里写了就无效
SVG 作为 background-image 时，内联 data URL 更可靠
SVG 文件本身是文本，容易因路径错、MIME 类型不对、CORS 限制而加载失败。特别是当 SVG 放在 CDN 或跨域服务上时，background-image: url(https://cdn.example.com/icon.svg) 可能白屏且无报错。
更可控的做法是把 SVG 内容转成 data URL：用工具（如 在线 encoder）或构建脚本转成 url("data:image/svg+xml,%3Csvg...%3E")，直接嵌进 CSS。
- data URL 完全规避路径和跨域问题，适合小图标、装饰性图形
- 注意 XML 实体要编码：
→ <code>%3C，>→%3E，&→%26，否则解析失败 - 过长的 data URL 会让 CSS 体积膨胀，别对 >2KB 的 SVG 这么干
