Less编译不重写url()路径，浏览器按CSS文件位置解析；rootpath仅机械添加前缀且不处理~""和变量；relativeUrls=true在构建工具中不可靠；推荐使用根绝对路径或JS动态导入管理资源路径。
Less编译时url()路径不重写，浏览器却按CSS位置解析
Less本身不做路径修正——它把url("img/logo.png")原样输出到CSS里，而浏览器加载时，是按最终生成的CSS文件所在目录去拼接路径的。比如dist/css/app.css里写了url("img/logo.png")，浏览器就会请求dist/css/img/logo.png，但实际图片可能在dist/img/logo.png。
rootpath参数只加前缀，不处理变量和~""包裹路径
rootpath就像个机械贴纸：只要url()里的路径不是以/、http或data:开头，它就自动在前面加指定字符串。但它完全无视url(~"assets/@{name}.png")这种写法——~""内部不支持变量插值，@{name}原样输出；~""本身也不会被rootpath修饰。
- 命令行用法：
lessc --rootpath=dist/ styles.less dist/css/styles.css→url("img/icon.svg")变成url("dist/img/icon.svg") - 必须确保
dist/这个前缀和你实际部署后的URL结构一致（比如CSS在/css/，图片在/img/，那rootpath设成"../"才对） -
url(/static/logo.png)这类绝对路径不受rootpath影响，也不需要它
relativeUrls=true在构建工具中基本不可靠
设relativeUrls: true本意是让所有相对路径转成相对于CSS输出目录的路径，但它依赖Less对导入链的路径推断，而Webpack/Vite等工具介入后，这个推断经常错乱。常见表现是：url("../fonts/a.woff2")被错误转成url("../../fonts/a.woff2")，尤其多层@import时几乎必翻车。
- 默认值是
false，也就是保持源码里写的路径字面量不变——反而更可控 - 不要指望它“智能修正”，它没有上下文感知能力
- 在
less-loader里配relativeUrls: true，往往比不配还容易出错
真正能落地的路径写法只有两种
要么走Web根目录绝对路径，要么靠构建工具接管路径解析。手写相对路径（如../assets/）在任何现代构建流程里都属于高危操作。
立即学习“前端免费学习笔记（深入）”；
- 推荐方案：图片放
public/assets/，Less里写url("/assets/logo.png")——路径明确、环境无关、无需额外配置 - 需哈希/压缩时：用JS动态导入，例如
import logo from "@/assets/logo.png"，再通过:style="{ backgroundImage: `url(${logo})` }"注入，让Webpack/Vite全程管理路径 - 千万别写
url(~"assets/@{file}.png")——~""里变量不展开，@{file}就是纯文本，最后生成url("assets/@{file}.png")，必然404
MiniCssExtractPlugin.publicPath或vite.config.js里的base配置——它们才是真正决定浏览器最终请求地址的开关。 
