根本原因是路径解析位置错位：Less只原样输出url()字符串，浏览器却按最终CSS文件位置请求资源；rootpath仅给非绝对url自动加前缀，不处理~""内路径或变量插值，relativeUrls在构建工具中极易失效。
url路径在Less里为什么总出404
根本原因不是字符编码，而是路径解析位置错位。Less编译器不关心文件系统结构，它只按字符串原样输出 url() 内容；但浏览器加载资源时，是相对于最终生成的 CSS 文件位置去请求的。如果你的 styles.less 在 src/less/，而编译后 CSS 被写入 dist/css/，那所有 url("images/logo.png") 就得按 dist/css/images/logo.png 去找——可实际资源可能在 dist/images/。
rootpath参数到底改了什么
rootpath 只影响编译后 CSS 中的 url() 和 @import 字符串开头，**不修改 Less 源码里的导入路径，也不重写变量拼接结果**。它像一个前缀“贴纸”，编译时自动加在每个未以 /、http、data: 开头的 url 值前面。
- 命令行用法：
lessc --rootpath=dist/ styles.less dist/css/styles.css→url("images/icon.svg")变成url("dist/images/icon.svg") - 浏览器端配置：
less = { rootpath: "dist/" };，必须放在<script src="less.js"></script>之前 - 注意：
rootpath不会处理~""包裹的 url，也不会修复变量插值失败（比如url(~"assets/@{name}.png")中的@{name}根本不会被替换）
relativeUrls设为true反而更易出错
relativeUrls: true 的本意是把所有 url 转成相对于 CSS 输出目录的相对路径，但它依赖 Less 对导入链的路径推断，而这种推断在多层 @import 或构建工具介入时极不可靠。实际中它常把 url("../fonts/a.woff2") 错误地转成 url("../../fonts/a.woff2")，尤其在 Webpack + less-loader 场景下基本失效。
- 默认值是
false，即保持源码中写的路径字面量不变 - 设为
true后，如果源码里写了绝对路径（如url("/static/img.png")），它不会动；但对相对路径会尝试“标准化”，结果往往和预期相反 - 真正可控的做法是：统一用
~""包裹所有 url，并确保路径按最终 CSS 位置来写（例如 CSS 在dist/css/，就写url(~"../img/icon.svg")）
最容易被忽略的路径陷阱
很多人卡在 url(~"assets/@{file}.png") 这类写法上——~"" 内部不支持插值，@{file} 就是纯文本，最后生成的是 url("assets/@{file}.png")，浏览器当然 404。正确做法永远是先拼好字符串再包：
立即学习“前端免费学习笔记（深入）”；
code
@file: "logo.svg";
@full-path: "assets/@{file}";
background: url(~"@{full-path}");
另外，rootpath 和 relativeUrls 都无法解决运行时动态路径问题（比如通过 JS 切换主题导致字体路径变化），那种场景必须交给前端代码做 encodeURIComponent() 或服务端重写，Less 编译阶段管不到 HTTP 层的事。
