Sass 5.0 前不解析 min()/max()，仅作字符串输出；5.0+ 默认交由浏览器运行时计算，故不支持混合单位且受浏览器兼容性限制。
为什么 min() 和 max() 在 Sass 中不能直接当 CSS 函数用
你在 Sass 文件里写 min(1rem, 2em)，编译后发现它原样输出成 CSS，浏览器报错：「Invalid property value」——这不是你漏写了单位，而是 Sass 5.0 之前压根不解析这些函数，只当普通字符串；5.0+ 虽支持，但默认走的是 **CSS 运行时计算 **，不是 Sass 编译时计算。
这意味着：如果参数里有变量（比如 $gap），而这个变量依赖于上下文（如主题色、断点），Sass 就没法在编译阶段确定结果，只能把 min() 推给浏览器。但浏览器的 min() 不支持混合单位（1rem + 2px）或某些旧版本（Chrome
- 想让边界值在编译期就“拍板”，得用 Sass 原生的
math.min()和math.max()（需开启@use "sass:math"） - 若目标浏览器明确支持，且参数全是 CSS 可算值（如纯数字、同单位长度），才放心用原生 CSS
min()/max() - 混用单位（
min(1rem, 20px)）必须由 Sass 计算，否则运行时报错或回退为无效值
在 @mixin 里安全封装边界逻辑的写法
别把 min() 直接塞进属性值里了，尤其当参数来自用户传入或配置文件时。混合宏里要做两层判断：先看能不能静态计算，再 fallback 到 CSS 函数。
示例：一个限制最大宽度又不小于最小内容宽度的混合宏：
立即学习 “ 前端免费学习笔记（深入）”；
@use "sass:math"; @mixin safe-width($min: 320px, $max: 100%) {// 编译期可算？同单位且非 null @if math.is-number($min) and math.is-number($max) {width: math.max($min, math.min($max, 100%)); } @else {// 否则交给浏览器，加注释提醒兼容性 width: max(#{$min}, min(#{$max}, 100%)); // ⚠️ requires CSS clamp() support} }- 用
math.is-number()判断是否能静态计算，避免math.min(null, 100%)报错 - 单位不一致时（如
$min: 2rem,$max: 400px），Sass 无法比较，必须 fallback 到 CSS 函数 - 不要在 mixin 里无条件拼接字符串（如
"#{$min}"），这会丢失类型信息，导致后续math.*调用失败
clamp() 和 min()/max() 的实际取舍场景
很多人以为 clamp(min, val, max) 是 min(max(val, min), max) 的语法糖，其实不是：它强制中间值是「首选值」，浏览器优先尝试渲染它，再按需收缩或扩张；而嵌套 min/max 是纯数学裁剪，没有优先级语义。
- 做响应式字号或间距？用
clamp()，它能配合视口单位产生平滑过渡（如clamp(1rem, 2.5vw, 1.5rem)） - 做硬性边界兜底（如“不能小于容器内边距，也不能超过父容器 80%”）？用
min(max($val, $min), $max)更直观 - Sass 里想提前算出具体数值（比如生成固定像素的媒体查询断点）？只能靠
math.min()/math.max()，clamp()是纯运行时行为
容易被忽略的单位隐式转换陷阱
Sass 对单位的处理比看起来更脆弱。比如 math.max(16px, 1rem) 不会自动转换单位，直接报错「Incompatible units px and rem」；而 max(16px, 1rem) 交给浏览器时，它反而能算——但前提是两个值单位可比（现代浏览器支持 rem/px 混合）。
- 想让 Sass 安全比较，必须统一单位：
math.max(16px, 1rem * 16)（假设 1rem = 16px） - 别依赖
1rem在编译期等于某个像素值——它取决于根字体大小，而那是运行时决定的 - 用
@debug math.max(10px, 2em)测试时，如果没报错，说明你当前em基准是已知的（比如在@function内部作用域里定义了），否则会炸
最稳妥的做法：边界值混合宏里，对单位敏感的参数加类型校验，或者文档里明确写死「仅接受相同单位」。不然一次重构，所有 @include responsive-container(2rem, 500px) 全挂。
