Less中字体路径404的根本原因是@icon-font-path等变量需按编译后CSS文件位置计算，而非.less源文件位置；必须确保CSS中url()路径与部署后真实资源URL一致，优先检查Network面板实际请求URL。
Less 里写的字体路径在编译后变成 404，不是 Less 编译错了，而是 @icon-font-path（或类似变量）的基准位置被误判了——它必须按最终生成的 CSS 文件所在位置来算，而不是 .less 源文件的位置。
字体路径必须相对于输出 CSS 文件位置计算
Less 不会自动调整路径层级。你写 @icon-font-path: "../fonts"，它就原样输出到 CSS 里；浏览器加载时，是按 dist/css/main.css 的位置去拼 dist/css/../fonts/icon.woff2，也就是 dist/fonts/icon.woff2。如果真实字体在 dist/static/fonts/，那就必然 404。
- 检查编译后 CSS 中
@font-face块里的url()路径，和你部署后的真实资源 URL 是否一致 - 路径写法要严格匹配构建产物结构：CSS 输出到
dist/css/，字体在dist/fonts/→@icon-font-path: "/fonts"（绝对路径）或"../../fonts"（相对路径） - 别用
@icon-font-path: "@/assets/fonts"—— Less 本身不识别 Webpack/Vite 的 alias，@会被当字面量输出
qiankun 子应用中字体请求发错域名
子应用 CSS 被 qiankun 提取为内联 后，url("./fonts/icon.woff2") 的解析基准从子应用自身域名变成了主应用根路径，结果请求发到了 https://main.com/fonts/icon.woff2。
- 最稳方案：改用绝对路径，如
url("/subapp/static/fonts/icon.woff2")，并确保 Nginx 或 CDN 将/subapp/static/正确代理到子应用静态资源目录 - 次选方案：统一配置 Webpack 的
publicPath或 Vite 的base，再在 Less 里用变量拼接，例如@font-url: "@{base-url}/fonts/" - 别依赖
file-loader或url-loader自动重写 —— qiankun 的样式沙箱会绕过这些 loader 的路径替换逻辑
content 插值必须用 ~"@{var}" 转义
直接写 @icon-home: "\e900" 再 content: @icon-home，浏览器收到的是字面字符串 "\e900"，不会解析成 Unicode 字符。更隐蔽的问题是：如果你用变量拼接字体路径，比如 url("@{font-path}icon.woff2")，Less 默认不展开插值。
- 正确写法：
url(~"@{font-path}icon.woff2")——~""表示这是需要插值的字符串 -
~""内部不支持嵌套插值，所以@font-path: "../fonts/"; url(~"@{font-path}icon.woff2")是 OK 的，但url(~"../fonts/@{name}.woff2")中的@{name}不会被替换 - 字体码点必须和
font-family分离使用，否则无法批量维护；content: @icon-home前必须确保@icon-home已定义为带引号的 Unicode 字符串，如@icon-home: "\e900"
最容易被忽略的一点：路径问题永远优先查 Network 面板里字体请求的实际 URL 和状态码，而不是反复改 @icon-font-path 变量。404 就调路径，CORS 就配响应头，乱码八成是 font-family 名不匹配或漏了 format("woff2")。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
