CSS变量不能直接用于background-image，因var(--path)展开后缺少url()函数包裹且未加引号，导致非法值被忽略；Sass/Less路径拼接受限，构建工具路径解析基于源文件位置，可靠方案是SCSS插值+构建别名+资源哈希化处理。
为什么 background-image: var(--path) 不生效
因为 CSS 变量展开后只是纯字符串字面量，比如 --path: ./img.png，展开为 background-image: ./img.png —— 这根本不是合法的 CSS 值，浏览器直接忽略，不报错也不加载。CSS 的 url() 是一个函数，必须显式书写，不能靠变量“自动补全”。
url(var(--x)) 写法为何必须加引号
路径字符串里若有空格、括号、中文或特殊字符（如 ./icons/arrow (dark).svg），不加引号会导致解析中断，浏览器只取到 arrow 就停了。引号把整个值当作一个原子单位处理：
-
--icon: "./icons/close.svg";✅ 安全 -
--icon: ./icons/close.svg;❌ 路径含空格或点号时大概率失败 -
background-image: url(var(--icon));✅ 必须保留url()包裹
Sass/Less 中拼接路径的坑在哪
Sass 的 url() 不接受运行时拼接表达式，url("assets/" + $name + ".png") 直接编译报错。Less 的 data-uri() 更脆弱：路径含变量就静默 fallback 为空字符串，SVG 带 BOM 或 XML 声明也会解码失败。
- Sass 必须用
#{"assets/" + $name + ".png"}插值，且$name必须是字符串类型 - Less 的
data-uri()路径必须是字面量，@path: "icon.svg"; data-uri(@path)❌ 无效 - 所有构建工具（Webpack/Vite）对
url()的路径解析都基于源文件位置，和最终 CSS 加载位置无关 —— 这才是 404 的真正根源
真正可控的路径管理方式
别依赖 CSS 变量或预处理器函数去“动态生成资源地址”，它们都在编译期或声明期失效。可靠做法是：
立即学习“前端免费学习笔记（深入）”；
- 用 SCSS 变量统一定义基础路径，例如
$assets: "/static";，再通过插值注入：background-image: url(#{$assets + "/logo.png"}); - 在构建配置中设置资源别名（如 Webpack 的
resolve.alias或 Vite 的resolve.alias），让url("@/assets/logo.png")被正确解析 - 静态资源全部走构建工具处理（
file-loader/asset模式），让路径变成哈希化后的绝对 URL，彻底避开相对路径歧义
变量本身不解决路径问题，它只是个字符串容器；真正起作用的是构建阶段的路径重写和运行时的资源定位机制。漏掉其中一环，var(--x) 就永远只是个安静的字符串。
