SCSS无法运行时检测浏览器特性，仅支持编译期人工预判与条件编译；@supports必须原样输出为CSS规则，由浏览器运行时执行，不可嵌入SCSS指令中。
SCSS 本身不支持运行时浏览器特性检测
SCSS 是编译时预处理器，不是 JavaScript，它无法读取 navigator.userAgent 或调用 CSS.supports()。所谓“检测浏览器特性”在 SCSS 层只能是**人工预判 + 条件编译**，本质是开发者根据目标浏览器范围，手动决定哪些 CSS 规则该保留、哪些该降级或补全。
@supports 不能直接写在 SCSS 变量或混合器里
@supports 是原生 CSS 规则，必须以完整声明块形式存在；SCSS 的 @if、@each 等指令只作用于编译期变量值，不能生成动态 @supports 块——除非你把整个 @supports 当作字符串拼接进去（不推荐，可读性差且易出错）。
正确做法是：把 @supports 当作普通 CSS 规则写在 SCSS 中，由 SCSS 原样输出，让浏览器自己运行时判断：
.button {
background: #007bff;
padding: 8px 16px;
<p>@supports (background: linear-gradient(to right, #007bff, #0056b3)) {
background: linear-gradient(to right, #007bff, #0056b3);
}</p><p>@supports (inset(0)) {
clip-path: inset(0);
}
}- 所有
@supports内部的声明都会被原样保留到最终 CSS，不参与 SCSS 编译逻辑 - 不要试图用
@if $has_clip_path包裹@supports—— 这会报错，因为@supports不是 SCSS 指令 - 多个
@supports可嵌套或并列，但不能用 SCSS 的and/or重写语法（例如@supports (display: grid) and (gap: 1rem)必须手写，不能拆成两个@if）
用 SCSS 变量模拟“特性开关”，仅限编译期决策
当你需要为不同构建环境（如 legacy / modern）输出不同 CSS，可以用布尔变量控制规则是否生成：
立即学习“前端免费学习笔记（深入）”；
$enable-modern-features: true;
$enable-css-grid: $enable-modern-features and (not $legacy-build);
<p>.container {
@if $enable-css-grid {
display: grid;
grid-template-columns: repeat(auto-fit, minmax(300px, 1fr));
} @else {
display: flex;
flex-wrap: wrap;
}
}- 这种“开关”只影响 SCSS 编译结果，和浏览器实际能力无关
- 适合 CI/CD 中通过环境变量切换
$legacy-build: true，生成两套 CSS - 注意：不要把它当成运行时兼容方案——如果现代浏览器加载了 legacy CSS，那些
@if分支根本不会存在
真正可靠的渐进增强必须靠 CSS 层级顺序 + 回退机制
浏览器解析 CSS 是从上到下、从左到右覆盖的。利用这一点，比任何 SCSS 技巧都更稳定：
.card {
padding: 12px; /* 所有浏览器 */
padding: clamp(12px, 4vw, 24px); /* 支持 clamp() 的浏览器覆盖上一行 */
}
<p>.input-field {
border: 1px solid #ccc;
border-radius: 4px;
/<em> 无 JS 时 fallback </em>/
background: #fff;</p><p>@supports (background: paint(some-worklet)) {
background: paint(some-worklet);
}
}- 回退值写在前，新特性写在后，浏览器自动忽略不支持的声明
-
@supports块内仍要遵循此原则：先写基础样式，再写增强样式 - SCSS 能做的只是帮你组织好这个顺序，而不是代替浏览器做判断
最常被忽略的一点：所谓“检测”，在 CSS 生态里从来不是 SCSS 的事——它是 @supports 的事、是属性回退顺序的事、是构建流程中多目标输出的事。SCSS 只负责让你少写重复代码，不负责猜浏览器想什么。
