Less 不支持运行时特性检测，仅能在编译时基于变量或函数做静态判断；@supports 必须手动编写且无法被 Less 逻辑控制；伪条件分支仅反映构建配置，与浏览器实际能力无关。
Less 本身不支持运行时特性检测
Less 是编译时预处理器，无法像 JavaScript 那样在浏览器中检测 supports() 或查询 DOM 特性。所谓“条件表达式”只能基于变量、函数返回值或 mixin 参数做静态判断，不是真正的 CSS 特性检测。
如果你期望的效果是“如果浏览器支持 inset，就用它；否则回退到 margin”，那必须靠外部手段（如 PostCSS 插件）或手动维护兼容方案，Less 自身做不到自动探测。
用 @supports 模拟特性检测需手动写死
你可以把 @supports 规则原样写进 Less 文件，它会在编译后保留为 CSS，但不能被 Less 的逻辑控制——也就是说，你不能用 if() 或 when 去包裹它并动态生成。
常见错误是试图这样写：
立即学习“前端免费学习笔记（深入）”；
.box {
.if-supports-inset() when (some-condition) {
@supports (inset: 0) {
inset: 0;
}
}
}
这会报错，因为 @supports 是 CSS 规则，不是 Less 可执行的语句。正确做法是直接写出带 @supports 的块：
PigX UI Pro 前端开发指南 - Vue 3 + TypeScript + Element Plus。当用户提到 PigX UI、PigX 前端、lgb-mgui 项目、Vue 3 企业级后台开发、Element Plus 后台开发时使用此技能。
.box {
margin: 20px;
@supports (inset: 0) {
margin: 0;
inset: 0;
}
}
-
@supports内容不会被 Less 编译，原样输出 - 所有判断逻辑必须由开发者预先决定哪些特性要检测、哪些要回退
- 不能用
isnumber()、iscolor()等函数去模拟浏览器能力
用变量 + mixin 实现“伪条件分支”
当你要根据项目配置切换样式行为（比如是否启用新特性），可以用变量控制 mixin 输出，但这和浏览器实际能力无关，只反映构建时决策。
例如：
@use-inset: true;
.inset-aware(@selector) when (@use-inset = true) {
@{selector} {
inset: 0;
}
}
.inset-aware(.box);
编译后生成 .box { inset: 0; }；若把 @use-inset 设为 false，该规则就不输出。
- 适合统一开关控制某组实验性样式
- 变量值必须在编译前确定，无法响应用户设备或运行时环境
- 不要混淆它和
@supports：前者是构建期开关，后者是运行时检测
真正需要特性检测时，应该交给 CSS 或 JS
Less 不是解决这个问题的工具。如果你的场景确实依赖运行时能力判断，优先顺序应该是：
- 直接写
@supports块（推荐，零成本，标准支持） - 用 JavaScript 动态加 class（如
supports-inset），再写对应 CSS - 用 PostCSS 插件如
postcss-feature-tests自动生成回退
Less 在这里只负责组织结构、变量复用和嵌套管理，别让它承担它设计之外的责任。
最容易被忽略的一点：很多人以为 if() 函数能判断 CSS 能力，但它只能判断 Less 表达式类型（比如 isstring(@x)），跟浏览器毫无关系——这个边界划清楚，能省掉大量无效调试。
