Less变量编译期替换，零运行时开销；CSS变量需运行时查找继承计算，有轻微样式计算负担。二者职责不同：Less负责构建期确定值，CSS变量负责运行时动态更新。
Less变量编译期替换，零运行时开销
Less变量（如@color）在构建阶段就被替换成具体值，最终输出的CSS里完全不包含变量痕迹。这意味着浏览器解析、计算、渲染时根本不需要处理变量逻辑——没有查找、没有继承、没有重绘触发。一个@spacing: 8px被替换成margin: 8px后，性能表现和手写CSS完全一致。
常见错误现象：有人以为“Less变量越多越慢”，其实编译速度可能略降，但和运行时性能无关；真正拖慢页面的是JS批量操作DOM或冗余CSS规则，不是@x本身。
- 构建时开销取决于变量数量和嵌套深度，但现代less-loader基本可忽略
- 输出体积略小——没有
var(--x)字符串和回退值冗余 - IE11完全兼容，无需polyfill或降级配置
CSS变量（--x）带来轻微样式计算负担
CSS自定义属性是真实存在的CSS属性，浏览器必须在渲染流程中实时查找、继承、合并、计算。每次调用var(--x)，引擎都要沿DOM树向上遍历直到找到最近声明的--x，再参与calc()或函数计算。这不是“很慢”，但确实比硬编码值多几步。
使用场景中容易被忽略的点：大量嵌套var(--a, var(--b, var(--c)))会延长样式计算链；更隐蔽的是，var(--size)用于width和padding时，若--size在父元素被JS频繁修改，可能触发多次layout重排。
立即学习“前端免费学习笔记（深入）”；
- Chrome/Firefox/Safari对
var()优化已很好，单次查找成本微乎其微 - 真正影响性能的是“高频变更+高权重属性”组合，比如每帧都改
--transform-x并用于transform -
getComputedStyle(element).getPropertyValue('--x')比读element.style.color略重，但差距在纳秒级
混用Less和CSS变量时的性能陷阱
Less里写~"var(--x)"看似无害，但容易掩盖两层开销：一是Less编译器要识别转义语法、拼接字符串；二是最终CSS里多了无法压缩的var()调用。如果项目用@import "theme.less"定义主题色，又在组件里用~"var(--primary)"引用，就等于放弃了Less的编译期计算优势，却没获得CSS变量的动态能力——因为--primary可能根本没在HTML中声明。
参数差异明显：@primary支持@primary * 2这种运算，而var(--primary)只能用于属性值上下文，不能直接参与Less算术。
- 不要在Less中用
~"var(--@{name})"替代@name，除非明确需要运行时更新 - 避免在媒体查询里混用：Less的
@sm: 576px可直接写@media (min-width: @sm)；而@media (min-width: var(--sm))仅Chrome 119+支持，旧版直接失效 - 构建工具如Webpack不会自动为
~"var(--x)"注入:root { --x: ... }，漏定义就会回退到unset
选型关键不在“谁更快”，而在“谁该负责哪部分”
性能对比不是为了分高下，而是划清职责边界：Less变量适合做构建期确定的事——颜色映射、断点数值、字体比例；CSS变量适合做运行时不确定的事——用户主题切换、动画进度、组件尺寸响应式调整。
最容易被忽略的是命名冲突与作用域泄漏。Less变量@gap只在当前文件或导入链内有效；而--gap一旦在:root声明，所有组件都能读写。一个第三方UI库悄悄改了--gap，你的卡片间距可能就崩了——这和性能无关，但会让调试变成噩梦。
