autoprefixer 混合宏已淘汰，真正生效的是构建工具层的 postcss autoprefixer 插件；需确保 postcss.config.js 正确配置、browserslist 目标明确，并检查最终打包的 css 文件而非开发中间产物。
autoprefixer 混合宏为什么没生效？
直接写 @include autoprefixer 不会自动加前缀——Sass 本身不内置这个功能，所谓“autoprefixer 混合宏”其实是早期手写或第三方库（如 compass）的遗留用法，现在基本已淘汰。真正起作用的是构建工具层的 autoprefixer 插件，它在 CSS 编译后阶段工作，和 Sass 的 @mixin 无关。
常见错误现象：@include flex 或自定义 @include transition 在编译后仍无 -webkit- 前缀；或者开发时看到前缀，上线后消失——大概率是构建流程里没启用 autoprefixer 或配置被覆盖。
- 不要依赖 Sass 混合宏处理前缀，那是伪解决方案，维护成本高且易漏
- 确保你用的是 PostCSS +
autoprefixer（不是 Sass 插件），并在postcss.config.js中正确配置browserslist - 检查构建命令是否实际调用了 PostCSS：Webpack 要配
postcss-loader，Vite 默认集成但可能被css.preprocessorOptions.sass配置意外绕过
PostCSS autoprefixer 的最低必要配置
前缀加不加、加哪些，完全取决于 browserslist 配置，不是 autoprefixer 版本越新越好。比如写 "last 2 versions" 可能导致给 Chrome 120 也加 -webkit-，其实毫无必要。
推荐用明确目标环境，避免模糊表述：
- 在
package.json里加"browserslist": ["> 1%", "not dead", "Chrome >= 90"] - 确保
postcss.config.js启用了插件：module.exports = { plugins: [require('autoprefixer')] } - 如果用 Vite，不用额外装插件，但需确认没在
vite.config.js中禁用css.postcss.plugins - 执行
npx autoprefixer --info可验证当前配置实际覆盖的浏览器范围
Sass 里还值得写前缀混合宏吗？
极少情况需要：比如必须在 CSS 运行时动态生成带前缀的值（如 calc() 里嵌 env(safe-area-inset-bottom)），或兼容极老构建链路（如纯 Ruby Sass 无 PostCSS）。除此之外，写 @mixin transform($v) { -webkit-transform: $v; transform: $v; } 是倒退。
问题不止于冗余——手动维护前缀极易出错：
-
user-select在 Safari 15.4+ 已不需要-webkit-，但混合宏里还留着 -
gap在 Flex 布局中旧版 Safari 需要-webkit-，Grid 中又不需要，混合宏很难条件区分 - 不同属性的前缀演化节奏不同，靠人肉同步不可持续
如何验证前缀是否真加上了？
别只看开发服务器的 CSS 文件，那可能是未压缩、未经过 PostCSS 处理的中间产物。真正要检查的是最终打包输出的 .css 文件（如 dist/assets/index.xxxx.css）。
容易踩的坑：
- 用
npm run dev查看样式，但 dev server 可能跳过 PostCSS（尤其 Webpack 4 默认不启用） - 浏览器开发者工具里看到前缀，是因为 DevTools 自动补全（Chrome 会模拟显示），不代表真实 CSS 含有
- 使用
cssnano等压缩器时，若配置不当可能把前缀删掉（需设autoprefixer: false关闭其内置版本） - 用
stylelint检查时，若规则含declaration-property-value-blacklist，可能误报合法前缀为“废弃属性”
最稳妥方式：构建后打开 dist 目录下的 CSS 文件，搜索 -webkit- 或 -moz-，对照 browserslist 预期的最低版本做交叉验证。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
