sass 不计算 css 的 min()/max()，因其仅编译时透传字符串，运行时由浏览器解析；混单位需用 math.min()（同单位）或 @supports 降级，否则失效。
为什么 Sass 会“错误计算” CSS 的 min() 和 max()
它根本没在计算——Sass 不解析原生 CSS 的 min()/max()，所谓“错误”，其实是你误以为它在编译期执行了逻辑。
你在 Sass 文件里写 width: min(100%, 400px)，Sass 3.5–4.x 版本会原样输出到 CSS；5.0+ 默认仍透传给浏览器，除非你显式调用 math.min()。这不是 bug，是设计使然：CSS 函数属于运行时能力，Sass 编译器无权、也无法替浏览器做这个决定。
- 写
@if min($a, $b) > 2rem→ 直接报错，Sass 不认识这个函数 - 写
font-size: min(16px, 2vw)→ 编译后就是原样字符串，靠浏览器算 - 写
width: math.min(320px, 100%)→ 报错，单位不兼容，math.min()要求纯数值或同单位
min() 和 max() 在 Sass 里到底谁在算？
取决于你用的是哪个“min”：
-
min(1px, 2px)（无命名空间）→ Sass 5.0+ 尝试按数学函数处理，但仅限同单位数值；混单位（如1rem, 2em）直接报Incompatible units -
math.min(16, 24)→ Sass 编译期真计算，返回16，但不能带单位参与比较（math.min(16px, 24px)合法，math.min(16px, 2rem)不合法） -
min(#{$var}, 400px)或width: #{min($a, $b)}→ 错误！#{}是字符串插值，不是函数调用，min()还是未解析的文本
真正安全透传 CSS 函数的方式只有：width: min(#{$min-width}, #{$max-width})，且确保变量本身是字符串（如 $min-width: "1rem"），否则 Sass 会尝试转换单位并失败。
为什么 min(1rem, 20px) 在浏览器里有时失效？
不是 Sass 的问题，是 CSS 规范限制：现代浏览器（Chrome 90+、Firefox 79+、Safari 13.4+）才支持混合单位的 min()/max()；旧版 Safari 或 Android WebView 会直接丢弃整条声明。
- Chrome 84–89：支持
min(100%, 500px)，但min(1rem, 20px)解析为无效值 - iOS Safari 13.3 及更早：忽略含
min()的整条规则，不 fallback - IE 和部分 Electron 内核：完全不识别，连
@supports (width: min(0, 0))都返回 false
上线前必须用 @supports 包裹，并提供 max-width/min-width 降级，例如：@supports (width: min(0px, 0px)) { width: min(90%, 1200px); } @else { width: 90%; max-width: 1200px; }
怎么在 @mixin 里安全封装边界逻辑？
别硬拼 min() 字符串，先判断能否静态计算，再决定交给 Sass 还是浏览器。
- 用
math.is-number($val)和unit($val) == unit($other)判断是否可编译期计算 - 同单位且非 null → 调
math.max($min, math.min($max, 100%)) - 含变量、混合单位、或来自
map-get()的配置 → 必须 fallback 到max(#{$min}, min(#{$max}, 100%))，并加注释说明兼容性要求 - 永远避免
#{min($a, $b)}—— 这会触发 Sass 尝试解析，而它根本解析不了带单位的混合参数
最易被忽略的一点：Sass 的 math.min() 和 CSS 的 min() 语义不同——前者是纯数值裁剪，后者是布局上下文中的动态响应式选择。选错就等于把「适配逻辑」提前固化，失去流体性。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
