SCSS 3.4+ 默认将 / 视为除法运算符，导致 font: 12px/24px sans-serif 等合法CSS被误解析而报错；仅当两侧均为数字时才执行除法，否则抛出 SassError；可靠解法包括引号包裹、#{} 插值或拆分为独立属性。
SCSS里写/为什么有时被当除法、有时报错
SCSS 3.4+ 默认把 / 当作除法运算符，而不是 CSS 中的普通分隔符。这意味着 font: 12px/24px sans-serif 这种合法 CSS 会被 SCSS 解析成「12px 除以 24px 再除以 sans-serif」——后者根本不是数字，直接抛 SassError: Invalid CSS after "...px/24px": expected expression。
- 只有当
/左右两侧都是纯数字（或可转为数字的变量）时，SCSS 才执行除法；否则它会尝试解析但失败 - 像
line-height: 1.5或margin: 0 auto这类不含数字/数字组合的/不触发除法，但font简写里的/因含数字，首当其冲 - 启用了
style: 'expanded'或使用了@debug时，问题更容易暴露
三种可靠写法：绕过除法解析、强制保留斜杠
不用关掉整个除法特性（那会破坏真实计算），而是针对性处理歧义位置：
- 用引号包裹整个值：
font: "12px/24px sans-serif"—— 字符串不参与运算，原样输出 - 用
#{"..."}插值兜底：font: #{'12px/24px sans-serif'}—— 强制按字符串拼接，适合动态拼接场景 - 拆成独立属性：
font-size: 12px; line-height: 24px; font-family: sans-serif—— 彻底避开/，语义更清晰，也利于后续维护
哪些地方的/其实安全？哪些必须处理？
不是所有斜杠都危险。SCSS 对上下文有基本判断：
- 安全（不触发除法）：
url(./img/icon.svg)、content: "/"、background: linear-gradient(to right, red, blue)里的逗号和方向词 - 高危（极易出错）：
font、grid（如grid-template-columns: 1fr/2fr）、clip-path中带数字的斜杠 - 注意
calc()里的/：SCSS 不干预calc()内部，width: calc(100%/3)是安全的，但width: 100%/3（无 calc）就会被当除法
升级后老项目突然报错？检查font简写和grid声明
从 Sass 3.3 升到 3.4+ 或迁移到 Dart Sass 后，最常崩的就是这两处。尤其团队共用变量时，比如：
立即学习“前端免费学习笔记（深入）”；
$base-font: 16px;
$line-height: 1.5;
// ❌ 错误：SCSS 尝试算 16px/1.5 → 10.66667px，再拼上 sans-serif？语法直接不认
font: $base-font/$line-height sans-serif;
// ✅ 正确：用插值或拆解
font: #{$base-font}/#{$line-height} sans-serif;
// 或
font-size: $base-font;
line-height: $line-height;
真正麻烦的不是写法本身，而是这类错误往往不报在你改的那一行，而是在最终生成 CSS 时才爆红——得顺着 sourcemap 往回扒，容易卡在错误堆栈最底下那层。
