标准属性必须放在最后，否则会被厂商前缀覆盖；如.transform(@value)须按-webkit-transform→-ms-transform→transform顺序输出，颠倒则旧浏览器失效。
Less Mixin 里写前缀，顺序错了就白搭
标准属性必须放在最后，否则会被前面的厂商前缀覆盖。比如 .transform(@value) 必须按 -webkit-transform → -ms-transform → transform 的顺序输出，不能颠倒。
常见错误是把 transform: rotate(30deg) 放在最前，结果编译后浏览器只认第一行、忽略后面——尤其在旧版 Safari 或 IE10 下直接失效。
- 厂商前缀不是越多越好：
-o-transform对现代 Opera 已无效（它用 Chromium 内核），加了反而增加体积 -
-ms-前缀仅对 IE10/IE11 有效，IE9 及更早需回退到filter或 JS 方案，Mixin 无法覆盖 - 不要在同一个声明块里混用新旧语法，比如
display: -ms-flexbox; display: flex;是安全的，但flex-direction: row; -ms-flex-direction: row;在 IE10 下可能行为不一致
哪些属性值得封装成带前缀的 Mixin？
不是所有 CSS 属性都需要 Mixin 补前缀。优先封装那些「目标浏览器支持度碎片化 + 值类型稳定」的属性，比如 user-select、appearance、transform、transition。
像 gap、place-items 这类现代布局属性，IE 完全不支持，加 -ms- 没意义；而 calc() 本身是运行时计算，Less 编译期不执行，Mixin 里写 width: calc(100% / 3) 会直接报 Operation 错误。
立即学习“前端免费学习笔记（深入）”；
- 推荐只封装明确需要且长期不变的前缀组合，例如：
.user-select(@value)输出三行，不多不少 - 避免封装
flex类布局属性——IE10 的-ms-flexbox和现代flex行为差异大，靠 Mixin 无法等价替代 - Mixin 参数必须强制传入，不设默认值。比如
.transition(@prop, @time)，而不是.transition(@prop, @time: 0.3s)，防止默认值掩盖兼容性问题
手写 Mixin 和 Autoprefixer 能不能共存？
能共存，但必须互斥作用于同一声明——如果 Mixin 已输出 -webkit-transform，Autoprefixer 就会跳过整条 transform 声明，不再补 -ms- 或 transform 标准属性。
换句话说：你写了手动前缀，就等于主动放弃 Autoprefixer 的自动化能力。这不是 bug，是设计机制。
- 项目里已有大量手写前缀的 Less 文件？先全局搜索
-webkit-、-moz-、-ms-，删干净再接入 Autoprefixer - 想保留部分 Mixin（比如内部工具中固定用 Safari 12+）？确保这些 Mixin 不和 Autoprefixer 处理的同一文件路径重叠
- 最稳妥的做法：全项目统一用 Autoprefixer，Mixin 只用于逻辑复用（如
.btn-base()），不用于前缀生成
为什么删了 IE11 配置，CSS 里还有 -ms- 前缀？
因为手写的 -ms-flexbox 不会自动消失，Autoprefixer 也不会清理它。它只负责“添加”，不负责“删除”或“修正”。
你改了 .browserslistrc，但构建缓存没清，或者 postcss-loader 根本没读到配置文件，都会导致预期和实际不符。
- 检查
postcss-loader是否真在less-loader之后执行（Webpack 中 use 数组从右往左，less-loader应在最右） - 运行
npx browserslist确认当前生效的浏览器列表，别信配置文件名，要看实际输出 - 临时加一行
console.log('autoprefixer ran')到postcss.config.js插件数组里，验证它是否被调用
真正难的不是写几个 Mixin，而是判断哪条声明该交给人写、哪条该交给工具链。多数项目到了 2026 年，Autoprefixer 已足够可靠，手写前缀反而成了技术债源头。
