Less无法运行时检测浏览器，只能通过变量和混合在编译时生成多套带前缀的CSS规则，如同时输出display: -webkit-flex和display: flex，由浏览器自行忽略不支持的声明。
Less里怎么写浏览器前缀的条件判断
Less本身不支持运行时检测浏览器，所谓“条件判断”只能靠变量+混合（.mixin）+参数控制，本质是编译时分支，不是CSS的@supports降级逻辑。你写的.flex-center()在编译后就固定成一套CSS，不会根据用户浏览器动态切换。
- 用
@supports做真·运行时降级，必须留在CSS层，不能全交给Less生成 - Less里能做的，只是按需生成多套规则：比如同时输出
display: -webkit-flex和display: flex，再靠浏览器自己忽略不支持的那行 - 别试图在Less里用
if (@browser == 'safari')——它没这个能力，也不该有
用Less混合模拟@supports行为的常见写法
想让Flex布局在IE10+和现代浏览器都可用，又不想手写两遍前缀，可以定义一个带fallback的混合：
.flex-container(@dir: row) {
display: -webkit-box;
display: -ms-flexbox;
display: flex;
-webkit-flex-direction: @dir;
-ms-flex-direction: @dir;
flex-direction: @dir;
}
注意这里不是“判断”，而是“并列输出”。浏览器会自动丢弃不认识的声明，比如Chrome直接跳过-webkit-box和-ms-flexbox。
- 顺序很重要：把最老的前缀放前面，最新的标准属性放最后，避免被意外覆盖
- 不要省略
-ms-前缀——IE10/11只认-ms-flexbox，不认flex - 如果项目已放弃IE，就别生成
-ms-和-webkit-box，徒增体积
Less变量控制是否启用某类兼容规则
当团队要分环境构建（如dev保留所有前缀，prod只留必要前缀），可以用布尔变量开关：
立即学习“前端免费学习笔记（深入）”；
@enable-ie10-support: true;
.flex-align-center() when (@enable-ie10-support = true) {
-ms-flex-align: center;
align-items: center;
}
这样改一个变量就能批量控制整套IE10适配逻辑是否生效，比全局搜索替换安全得多。
- 变量名要见名知意，
@enable-ie10-support比@compat-mode更明确 - 避免用
@prefixes: 'all'这种字符串判断——Less的when条件不支持字符串相等比较（除非用isstring()等函数，但太绕） - 变量定义建议统一放在
variables.less里，别散落在各个文件中
为什么不能用Less替代postcss-autoprefixer
Less的前缀是静态的、基于开发者预设的；postcss-autoprefixer是动态的、基于browserslist配置和Can I Use数据实时计算的。后者能自动判断：Chrome 112要不要加-webkit-，Safari 16.4是否已支持aspect-ratio。
- Less混合一旦写死，就和浏览器演进脱钩；autoprefixer每次构建都查最新兼容表
- 维护成本差异巨大：你手动更新
.grid-area()混合来适配Firefox新Grid特性？不如让autoprefixer干 - 真实项目里，Less负责结构抽象（比如
.btn-primary），autoprefixer负责兼容兜底，分工才合理
真正难的不是写几个混合，而是厘清哪些该由Less管（设计系统原子类）、哪些该交给工具链（前缀、@supports包裹、CSS嵌套转义）。越早分开，后期越少返工。
