混合模式通过封装前缀逻辑到可复用代码块中避免重复书写，如定义.rotate() mixin后调用即可自动展开所有前缀，修改支持范围或新增属性只需更新一处，且能内置顺序控制、参数校验与降级兜底，提升安全性与可控性。
因为混合模式把前缀逻辑封装进可复用、可集中更新的代码块里，而手动写前缀是散落在各处的重复字符串，改一次要搜十次。
混合模式如何避免重复写-webkit-这类前缀
手动写前缀时，每个需要兼容老浏览器的属性都得单独加一遍，比如：
button {
-webkit-transform: rotate(45deg);
-ms-transform: rotate(45deg);
transform: rotate(45deg);
}
而用混合，只需定义一次：
.rotate(@deg) {
-webkit-transform: rotate(@deg);
-ms-transform: rotate(@deg);
transform: rotate(@deg);
}
调用时一行搞定：.rotate(45deg)，所有前缀自动展开。
- 前缀列表写在 mixin 内部，改浏览器支持范围时只动一处
- 新增属性（如
backdrop-filter）只需往 mixin 里加一行，不用翻遍所有 CSS 文件 - 不支持的前缀（如已废弃的
-moz-box-shadow）可以统一删掉，不会漏掉某处
为什么.transition()混合比手写transition更安全
手写容易漏掉前缀或写错顺序，比如把 -webkit-transition 放在标准属性后面，某些旧版 Safari 就会忽略它；混合则由开发者控制展开顺序和条件。
- 可内置判断逻辑：
if (is-old-safari) { ... }（通过变量或函数模拟） - 参数化后支持组合调用：
.transition(all 0.3s ease, opacity 0.2s)，避免手写时拼错逗号或空格 - 默认值兜底：未传参时自动补全
all 0.2s ease，减少遗漏 - 编译错误能暴露问题：比如传了非法单位（
.transition(500px)），mixins 内部可用isnumber()检查，而手写根本没检查机会
混合模式对 autoprefixer 的实际替代价值有限，但不可替代
现代项目大多用 autoprefixer 自动加前缀，那 Less 混合还有必要吗？有，而且关键在「可控性」。
-
autoprefixer只处理标准 CSS 属性，对自定义属性（如--my-var）、非标实验性语法（如display: flow-root）不生效，这些仍需 mixin 手动维护 - 当你要降级到 IE11 时，
autoprefixer不会生成-ms-前缀的grid，但你可以自己在 mixin 里加 - 团队规范要求“所有 transition 必须带 timing-function”，mixins 能强制约束，
autoprefixer不能 - 混合还能做更多事：比如同时注入前缀 + fallback 值（
background: #000; background: linear-gradient(...)），这是前缀工具做不到的
真正难的不是写一个 .flex() 混合，而是让所有开发者都记得用它——所以必须配合 lint 规则（如禁止直接写 display: flex）和文档约定，否则混合就只是个没人用的废文件。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
