单个@font-family-base变量不满足多场景分层覆盖需求，因标题、正文、代码块等需不同字体栈（如.code必须monospace），深色模式需整体替换，中英混排易回退失败，且Less编译器不解析引号/逗号逻辑，拼接易出错。
为什么单个@font-family-base变量很快就不够用
项目刚起步时，一个@font-family-base似乎能覆盖全部字体需求；但实际开发中，标题、正文、代码块、按钮、图标等场景对字体栈的要求完全不同。比如.code必须强制使用monospace，不能 fallback 到 sans-serif；深色模式下可能要整体替换为"SF Mono"而非"Consolas"；而中英混排时，把"PingFang SC"塞进英文栈末尾，会导致部分字符加载慢甚至回退失败。
更关键的是：Less 编译器不解析字体栈里的引号和逗号逻辑，直接拼接容易出错——例如@font-family-base: "Inter", -apple-system, sans-serif;写成@font-family-base: "Inter", -apple-system, sans-serif（漏掉分号）或中间多加空格，都可能让整个声明失效。
- 中文字体名含空格或中文时，必须加引号：
"Microsoft YaHei"✅，Microsoft YaHei❌ - 多个字体必须用逗号分隔，且整体不包裹在一对引号里（即不能写成
"'Inter', -apple-system, sans-serif"） - 构建工具（如 webpack + less-loader）只做字符串替换，不会校验字体栈是否合法，错误只能靠人工肉眼排查
用命名空间 + 混合封装语义化字体栈
把字体族按用途分组，用 Less 命名空间隔离，再通过混合统一输出，是目前最稳妥的集中管理方式。它不追求“运行时切换”，而是确保修改一处、全站响应，同时保留语义可读性。
示例结构：
立即学习“前端免费学习笔记（深入）”；
.fonts {
@sans: "Inter", -apple-system, BlinkMacSystemFont, "Segoe UI", sans-serif;
@mono: "SFMono-Regular", Menlo, Monaco, Consolas, "Liberation Mono", monospace;
@serif: "Charter", "Noto Serif", serif;
<p>.base() { font-family: @sans; }
.heading() { font-family: @sans; }
.code() { font-family: @mono; }
.ui() { font-family: @sans; }
}调用时直接写.fonts.base();或.fonts.code();，既避免重复书写font-family声明，又明确表达意图。如果某天要统一替换代码块字体，只需改@mono那一行。
- 命名空间防止变量污染，尤其当多个团队成员共用同一 Less 项目时
- 混合内部不硬编码具体字体值，全部引用命名空间内变量，保证联动更新
- 不建议在混合里加
!important或font-display——这些属于加载策略，应另用独立 mixin 封装
字号阶梯必须绑定基准 + 无单位倍数
用@font-size-sm: 12px;这种散落定义，后期调整会变成灾难。真正可控的方式是确立一个@font-size-base和一个@line-height-base，其余字号与行高全部基于它们乘法推导。
例如：
@font-size-base: 16px; @line-height-base: 1.5; <p>@font-size-sm: @font-size-base <em> 0.875; // 14px @font-size-lg: @font-size-base </em> 1.125; // 18px @line-height-md: @line-height-base * 1.2; // 1.8
这样改@font-size-base为18px，所有衍生值自动重算；而且line-height用无单位值，能随字号缩放，避免小字号挤在一起、大字号行距塌陷。
- 别在 mixin 里动态算
line-height: @font-size-base * 1.5——这会让编译结果冗余，且破坏行高与字号的解耦设计 - 媒体查询中重定义基准变量即可：
@media (max-width: 768px) { @font-size-base: 14px; }，后续所有依赖它的变量自动生效 - 组件级字号（如按钮）应显式声明
font-size，不要依赖父级继承，否则嵌套时极易错乱
中英混排和图标字体必须拆开管理
把中文字体和英文字体塞进同一个变量，表面省事，实则埋雷。浏览器对中英文字符的渲染路径不同，“Segoe UI”在 Mac 上不存在，“PingFang SC”在 Windows 上不生效，硬拼会导致部分字符突然变细或字形断裂。
推荐做法是拆成两个变量，并在使用时组合：
@font-family-en: "Inter", -apple-system, sans-serif;
@font-family-zh: "PingFang SC", "Microsoft YaHei", sans-serif;
<p>body {
font-family: @font-family-en, @font-family-zh;
}图标字体同理：单独定义@icon-font-name和@icon-font-path，并在@font-face中显式引用，避免和文本字体混用导致加载竞争或 fallback 失效。
-
@icon-font-path必须是相对于最终生成 CSS 文件的路径，不是 Less 源文件路径；Webpack 场景下常见错误是写成../fonts/icon.woff2，实际应为../../fonts/icon.woff2 - Unicode 码位必须声明为字符串：
@icon-home: "\e900";✅，@icon-home: \e900;❌；伪元素中必须用@{icon-home}插值 - 换图标库时，只改
@icon-font-name和@icon-font-path，其他地方无需动，前提是所有图标类都通过 mixin 或命名空间调用
字体管理真正的复杂点不在语法，而在跨平台渲染差异、编译链路路径解析、fallback顺序验证这三块。每次调整后，至少要在 Chrome / Safari / Edge 下分别检查中文、英文、数字、图标是否正常渲染，而不是只看一个浏览器。
