根本原因是浏览器按最终CSS文件位置解析url()相对路径，而Less仅原样输出不修正；推荐用根绝对路径、~前缀配合Webpack alias或resolve-url-loader解决。
打包后 url() 相对路径 404，不是 Less 写错了，而是浏览器按最终 CSS 文件位置解析路径，而 Less 编译时完全不修正它——url(../images/logo.png) 被原样输出，但生成的 dist/css/app.css 和图片实际存放位置（比如 dist/assets/images/）不匹配。
Less 本身不处理 url() 路径，只做字符串透传
Less 不是构建工具，它不关心资源在哪、也不重写 url()。你写的 url(../images/icon.svg)，编译后就是一模一样的字符串，丢进 CSS 里。真正决定请求地址的，是浏览器加载该 CSS 时，以 CSS 文件所在 URL 为基准计算相对路径。
- 开发时：CSS 在
/src/styles/main.less，图片在/src/assets/images/，你写url(../assets/images/...)看似合理 - 打包后：CSS 被输出到
/dist/css/app.css，浏览器就按/dist/css/../assets/images/→/dist/assets/images/去请求 - 但实际图片可能被复制到了
/dist/static/images/或/dist/assets/img/，路径自然错位
Webpack 项目中，file-loader/url-loader 对 Less 的 url() 无效
file-loader 和 url-loader 只接管 JS 中的 import 或 require()，对 Less 里的 url() 完全无感。即使你配置了 test: /\.(png|jpe?g|gif)$/i，它也不会扫描 CSS 或 Less 源码中的字符串。
- 错误预期：以为配了
url-loader就能自动哈希并替换所有图片路径 - 真实情况：只有 JS 里
import logo from '@/assets/logo.png'才触发处理 - Less 里的
url('./logo.png')仍原样输出，后续交给css-loader——而它默认不重写url()
三种可靠解法，按推荐顺序
别再赌相对路径在不同构建阶段“刚好对得上”，直接用明确可控的方式：
立即学习“前端免费学习笔记（深入）”；
-
根绝对路径：
background: url('/assets/images/logo.png');——跳过构建链路，但失去哈希和自动复制，适合 public/ 下静态资源 -
~ + Webpack alias：
background: url(~'@assets/images/logo.png');——必须在webpack.config.js中配好resolve.alias，且~必须紧贴引号内，不能写成url('~@assets/...') -
resolve-url-loader（仅限 Webpack）：加在
less-loader后面，它会根据输出 CSS 文件位置反向修正url()中的相对路径；但需注意它不支持@import (css)里的嵌套url()
Vite 用户注意：别用别名，也别信 additionalData 中的 @/
Vite 的别名只在 JS/TS 生效，additionalData 注入的 @import "@/styles/vars.less" 是静默失败，url('./xxx.png') 同理。Vite 默认不接管 Less 中的相对路径解析。
- 正确写法：
background: url('~@/assets/logo.png');（配合resolve.alias） - 或改用
public/目录：background: url('/logo.png'); - 千万别在
additionalData里写@import "@/..."或拼接变量路径如url("@{base}/x.png")——它不会展开，也不会被解析
最易被忽略的一点：~ 前缀是否真的被 less-loader 识别，取决于你是否同时配了 resolve.alias 且路径在镜像/构建环境中真实存在。Docker 构建失败、Vite HMR 不触发、AntD 主题文件 not found，八成卡在这一步——不是语法问题，是路径根本没抵达模块解析系统。
