@if 不能解决兼容性问题，因为它仅在 Sass 编译时静态分支选择，依赖预设变量而非运行时探测；真正兼容性需 Autoprefixer 或手动适配策略配合 @if 作开关。
@if 本身不生成跨浏览器兼容 CSS，它只做编译时静态分支选择；真正兼容性靠 Autoprefixer 或手动适配策略，@if 只能配合它们做“开关”或“配置路由”。
为什么 @if 不能直接解决兼容性问题
@if 在 Sass 编译阶段运行，完全不知道浏览器版本、用户设备或运行时特性支持情况。它只能根据你提前注入的变量（如 $env、$browser）决定输出哪段 CSS —— 这些变量必须由构建工具写死，不是自动探测出来的。
- 写
@if supports(-webkit-backdrop-filter)❌：Sass 不认识supports()，会直接报错 - 写
@if $browser == "safari17"✅：但前提是$browser已通过 Webpack DefinePlugin 或 Vitedefine注入，否则Undefined variable "$browser" - 误以为
@if能替代@supports❌：二者层级不同 ——@supports是 CSS 运行时规则，@if是编译前文本拼接
用 @if 配合 Autoprefixer 控制前缀开关
Autoprefixer 才是处理 box-shadow、flex 等兼容性的主力，@if 只适合在「要不要启用某套 polyfill 样式」这种二选一场景里当开关。
- 定义布尔开关变量：
$enable-legacy-flex: true;（在全局变量文件中声明） - 用
@if包裹需降级的样式块：@if $enable-legacy-flex { display: -ms-flexbox; } - 确保 Autoprefixer 仍作用于最终 CSS：即 Sass → CSS → Autoprefixer 流程不能断，且
browserslist配置要真实反映目标环境（例如包含"IE >= 11"） - 避免重复劳动：不要一边让 Autoprefixer 处理
transform，一边又用@if手动写-webkit-transform，会导致冗余和冲突
哪些兼容性场景真需要 @if + 手动 mixin
Autoprefixer 不覆盖的少数硬需求，才值得用 @if 做条件分发，典型如：
-
backdrop-filter：Safari 17.4 仍需-webkit-backdrop-filter，而标准版无前缀不生效 → 必须手写两行，且带前缀的放前面 -
filter: drop-shadow()：部分 Android WebView 对无前缀支持不稳定 → 可用@if $target-os == "android"控制是否插入-webkit-filter - 多端差异化（如 uni-app）：
@if $platform == "mp-weixin"加载微信小程序专用颜色变量，但注意：这必须配合@import条件引入，不能靠赋值覆盖（否则后赋值会覆盖前赋值）
最容易被忽略的作用域和执行时机
@if 的判断结果在编译完成那一刻就固定了，后续任何 JS 修改、CSS 变量切换、媒体查询匹配都不会触发重计算。
- 如果用
@use引入模块，$env必须在该模块内声明，或通过with显式传入，否则@if看不见它 - 调试时加
@debug $env;，确认输出的是字符串"production"而不是未定义或空值 - 多条件逻辑务必加括号：
@if ($env == "prod") and ($theme == "dark")，漏括号会导致and优先级错误
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
