Sass与CSS自定义属性（也就是通常所说的CSS变量）混合使用时，一个高频踩坑点就是类型问题。你在CSS变量里存了一个数字，比如--gap: 10px，然后在Sass里写$total: var(--gap) * 2，编译时立刻报错，提示这不是数字。为什么Sass要把var()的结果当成字符串？这篇文章就来彻底讲清楚背后的机制，并给出几种可靠的解决方案。
一、根本原因：Sass编译期与浏览器运行期的鸿沟
要理解这个问题，先要明白Sass变量$var和CSS变量--var是两套完全不同的机制。Sass变量在编译阶段就被求值并替换成具体的值，最终生成的CSS文件里根本看不到$var的影子。而CSS变量是浏览器在运行阶段才解析的，它的值可以随选择器作用域、继承关系甚至JavaScript操作而动态变化。
var()函数在Sass眼中是一个“不透明”的函数调用。Sass编译器不知道var(--gap)最终会解析成10px还是red，甚至可能根本不存在。它唯一能做的就是把这个函数原样输出到CSS中，并且给它一个通用的类型——字符串（在Sass中称为unquoted string，不带引号的字符串）。这并不是设计缺陷，而是唯一合理的处理方式：编译器无法预知运行时的值，自然无法把它归类为数字、颜色或布尔值。
可以用meta.type-of()函数验证这一点：
$value: var(--gap); @debug meta.type-of($value); // string，而不是 number
输出结果明确告诉我们类型是string。所以当你尝试对它做算术运算时，Sass会抛出类似“Undefined operation”的错误，因为字符串不能乘以数字。
二、常见错误场景与排查思路
第一种典型场景是直接对var()做算术运算。例如写width: var(--width) / 2，Sass编译器试图在编译期完成除法，但它发现左操作数是字符串，直接报错。第二种场景是把它传给Sass的内置函数，比如darken(var(--color), 10%)，颜色函数同样要求参数在编译期是确定的颜色值，var()显然满足不了。
第三种场景更隐蔽一些：插值和运算混用时结果不符合预期。有些开发者发现用插值#{var(--gap)}能让编译通过，于是以为问题解决了，其实插值只是把表达式转成字符串拼接，产出的仍然是文本，后续运算一样会出问题。排查这类问题的思路很简单：凡是参与Sass运算、内置函数调用的值，先用meta.type-of()打印类型确认一下，凡是返回string的，都不能用于编译期计算。
再补充一个容易混淆的点：如果var()出现在属性值的上下文中，Sass会把它作为整个声明的一部分原样保留，这没有问题；问题只出现在需要Sass主动求值的场景，比如算术表达式、函数参数、控制指令的条件判断等。
三、四种实用解决方案
1. 用calc()包装，把运算推迟到浏览器
既然Sass无法在编译期计算，那就把计算交给浏览器。calc()是原生CSS函数，浏览器在运行期解析完var()的值之后再执行运算，完美绕开类型问题：
:root {
--gap: 10px;
}
.box {
width: calc(var(--gap) * 2); // 编译后原样保留，浏览器计算得 20px
margin: calc(var(--gap) + 5px);
}这是最推荐的方案，兼容性在现代浏览器中已经非常好。需要注意的是，calc()内部的操作数单位要合法，比如两个带px单位的值相乘是无效的。
2. 定义时存两份：Sass变量与CSS变量同步
如果某个值既需要参与Sass编译期运算，又需要通过CSS变量动态调整，可以在源头维护一份Sass变量，再把它注入CSS变量：
$gap: 10px;
:root {
--gap: #{$gap};
}
.box-a {
width: $gap * 3; // Sass编译期计算，输出 30px
}
.box-b {
padding: var(--gap); // 运行期使用，输出 var(--gap)
}注意#{}插值在这里是必要的，因为CSS变量声明中的Sass变量如果不插值，某些旧版本编译器会有警告。这个方案牺牲了一点“单一数据源”的优雅，但换来两套机制各得其所。
3. 用@mixin和函数封装，控制运算边界
更工程化的做法是封装一个mixin，在内部用calc()处理CSS变量，调用方完全不用关心类型细节：
@mixin gap-margin($multiplier) {
margin: calc(var(--gap) * #{$multiplier});
}
.card {
@include gap-margin(3); // 输出 margin: calc(var(--gap) * 3);
}这样团队中其他成员即使不了解var()的类型陷阱，也不会误写出错误的运算表达式。
4. 运行时动态值的替代思路
如果值需要由JavaScript动态修改，那么Sass注定帮不上忙，只能依赖calc()组合，或者用JS直接读取getComputedStyle后计算再写回样式。此时应放弃“让Sass理解CSS变量”的执念，明确分工：Sass负责静态主题，CSS变量负责动态部分，calc()作为两者的桥梁。
四、方案对比与选型建议
下表总结了各方案的适用场景：
| 方案 | 编译期计算 | 运行期动态 | 适用场景 |
|---|---|---|---|
| calc()包装 | 否 | 是 | 值需要动态变化且需简单运算 |
| 双份变量同步 | 是 | 部分 | 主题系统中既有静态计算又有动态覆盖 |
| mixin封装 | 否 | 是 | 团队协作，统一约束写法 |
| JS配合 | 否 | 是 | 高度动态的交互场景 |
最后总结一句：var()被识别为字符串不是bug，而是Sass作为预处理器的能力边界。理解“编译期求值”与“运行期求值”的分界线，遇到类型错误时优先想到calc()，再考虑是否需要在Sass侧维护一份镜像变量，就能从容应对绝大多数场景。记住一个原则：凡是希望Sass计算的，用Sass变量；凡是希望浏览器动态解析的，用CSS变量配合calc()，不要试图让一个值同时扮演两种角色。