必须将 browserslist 配置、postcss 构建链与 ci 阶段 css 语法检查三者绑定，否则无法发现 gap、aspect-ratio 等在旧版 chrome/firefox 中失效的问题。
直接结论：不能只靠 Autoprefixer 单打独斗，必须把 browserslist 配置、postcss 构建链、CI 阶段的 CSS 语法检查三者绑死，否则上线前根本发现不了 gap、aspect-ratio 这类“看起来能用但实际在旧版 Chrome/Firefox 中失效”的问题。
为什么 Autoprefixer 自动加前缀 ≠ 兼容性有保障
Autoprefixer 只处理「已知需加前缀的属性」，比如 transform、flex；但它对新标准属性（如 contain、scrollbar-gutter）或部分已去前缀但尚未全平台稳定的属性（如 inset）完全不干预。更关键的是：它不报错、不拦截、不警告——哪怕你写了 display: grid 却要求支持 IE11，它也照常输出，最后白屏。
常见错误现象：
- 开发时在 Chrome 正常，测试时发现 Safari 15.6 下
backdrop-filter完全不生效（没加-webkit-，且该版本 Safari 要求强制加） - 打包后 CSS 里出现
color-mix()，但目标浏览器列表含 Firefox 91（不支持），构建过程零提示
所以必须补上两层防护：
- 用
stylelint+stylelint-no-unsupported-browser-features插件，在写代码阶段就标红不兼容写法 - 在 CI 的
build脚本里加一道postcss --config postcss.config.js --no-map src/styles.css -o /dev/null，靠 PostCSS 解析失败来卡住非法语法（比如误写的font-size: clamp(1rem, 2.5vw, 1.5rem)在低于 Chrome 84 的环境会解析报错）
如何让 browserslist 真正驱动整个工具链
browserslist 不是写在 package.json 里就自动生效的——不同工具读取它的优先级和方式不同。企业项目里最容易踩的坑是：Babel 读了，PostCSS 没读；或者 Vite 读了，Stylelint 没读。
实操建议：
- 统一用
.browserslistrc文件（而非package.json字段），路径放在项目根目录，内容示例：ie >= 11<br>chrome >= 87<br>firefox >= 78<br>safari >= 14.1<br>edge >= 90
- 在
postcss.config.js中显式传入：module.exports = {<br> plugins: [<br> require('autoprefixer')({ overrideBrowserslist: require('browserslist')() })<br> ]<br>} - Stylelint 配置中必须启用插件并指定源：
"plugins": ["stylelint-no-unsupported-browser-features"],<br>"rules": {<br> "plugin/no-unsupported-browser-features": [<br> true,<br> { "severity": "error", "ignore": ["-webkit-text-stroke"] }<br> ]<br>}
注意：overrideBrowserslist 参数在 autoprefixer v10+ 已废弃，必须改用 targets，否则 Vite 项目里可能 fallback 到默认值（defaults），导致检测宽松度过高。
CI 阶段必须验证的三个硬性检查点
仅靠本地开发时的 lint 和 build 不够。CI 流程里至少要跑通以下三项，任一失败即阻断发布：
-
npx stylelint "**/*.{css,scss,vue}"：捕获写死的不兼容属性（如place-items: center在 Safari 12.1 下无效） -
npx postcss src/assets/main.css --config ./postcss.config.js --no-map -o /dev/null：利用 PostCSS 解析器做语法级兼容校验（例如@container在未启用 container-query 插件时会直接 crash） -
npx caniuse-api --browsers "chrome 87, firefox 78" "aspect-ratio"：对关键业务组件用到的新属性做白名单式断言（脚本化调用，避免人工查 caniuse.com）
性能影响很小，单次总耗时通常
容易被忽略的「降级盲区」：滚动条、选择框、原生表单控件
这些元素的样式在各浏览器中差异极大，且 Autoprefixer 完全不覆盖。比如 ::-webkit-scrollbar 在 Firefox 和 IE 下无效，appearance: none 在 Safari 15.4 之前需要 -webkit-appearance，而 select 的下拉箭头在 Edge 18 和 Chrome 100+ 渲染逻辑完全不同。
解决方案不是写一堆 hack，而是：
- 用
postcss-custom-properties抽离滚动条颜色变量，配合@supports (scrollbar-width: thin)做 Firefox 专用规则 - 对
input[type="date"]这类控件，明确写死appearance: none+ 手动绘制图标，并在stylelint中禁用所有未加@supports包裹的appearance使用 - 把「是否启用自定义滚动条」做成构建时变量：
process.env.USE_CUSTOM_SCROLLBAR === 'true'，避免在仅支持 IE11 的客户环境中意外激活不兼容样式
真正难的从来不是加前缀，而是判断某个属性在目标环境里是「可用但需前缀」，还是「不可用必须降级」——这个决策点必须沉淀为可执行、可验证、可回滚的配置项，而不是靠人肉记忆。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
