加前缀不是目的，让样式在目标用户设备上生效才是；需依browserslist配置和真实终端覆盖率决定是否添加，autoprefixer仅按配置工作且不处理实验语法或修复缺失声明。
看 caniuse 数据，不是看“有没有前缀”而是看“要不要支持”
加前缀不是目的，让样式在目标用户设备上生效才是。比如 backdrop-filter 在 Safari 15.6 及以下必须用 -webkit-backdrop-filter，但如果你的 browserslist 配置是 "iOS >= 16"，那它就根本不用写——连原生属性都不该出现。
常见误判：看到 caniuse 上某属性标“部分支持”，就下意识加前缀。其实要看具体版本和引擎。例如 transform 在 Android Browser ≤4.4 必须加 -webkit-transform，但 Chrome 49+ 就完全不需要；gap 在 Flex 容器中 IE11 根本不识别，加前缀毫无意义，只能换 margin 模拟。
- 查 caniuse 时，点开具体浏览器条目，看“Full support”起始版本，而非“Partial support”那一栏
- 重点关注你项目实际覆盖的终端：iOS 版本比 Chrome 版本更难升级，Safari 14.5（2021年发布）至今仍有约 3% 市场份额，不能只盯 last 2 versions
- 对已明确不支持的特性（如 IE11 的
grid），不要加-ms-grid——它的语法和现代grid不兼容，写了等于引入新 bug
autoprefixer 不是万能的，它只按配置工作
autoprefixer 不会主动判断“这个属性值是否合法”，也不会修复你漏写的声明。比如你写 display: flex 却没写 flex-direction，某些旧版解析器可能直接丢弃整条规则，而 autoprefixer 照常加前缀，结果反而掩盖了问题。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 运行
npx autoprefixer --info确认当前配置实际覆盖哪些浏览器版本，避免依赖模糊表述如last 2 versions - 在 CI 中加入检查步骤：构建后 grep 输出 CSS，确认关键属性（如
-webkit-backdrop-filter）确实存在，而不是静默跳过 - 如果源码用了实验性语法（如
color-mix()），autoprefixer 不处理——它只管标准属性的前缀，不负责降级或 polyfill
有些特性加了前缀也白搭，得换思路
前缀只是表面一层，真正卡住的往往是底层限制。比如 -webkit-backdrop-filter 在 iOS Safari 中启用，需要同时满足三个条件：background-color（哪怕是 transparent）、父容器不能有 overflow: hidden、且不能是 position: fixed 的子元素。漏一条，加再多前缀也没用。
类似情况还有：
-
flex老语法（display: -webkit-box）和新语法混写，IE10/11 会直接忽略整个声明块 -
@supports (backdrop-filter: blur(1px))在 Safari ≤15.3 下不识别，检测失败，兜底样式进不去 -
:has()选择器即使加了@supports selector(:has(a))，Firefox ≤108 和 Safari ≤15.3 也完全无法解析该规则，整行被抛弃
真正要放弃兼容的时候，其实是“降级方案成本高于收益”
不是所有旧浏览器都值得保。比如为支持 IE10 写两套 Flex 布局 + 一堆 -ms- 前缀，还要测 overflow、min-height 行为差异，不如直接用 float 或 inline-block 做基础布局，再用 JS 动态加载现代样式——前提是你的用户里 IE10 占比低于 0.5%。
判断依据很实际：
- 埋点数据里，目标设备占比是否低于你设定的阈值（通常 0.5%～1%）
- 降级方案是否引入新维护成本（比如多一套媒体查询、额外 JS 判断逻辑）
- 设计稿本身是否已默认以现代浏览器为基准（如用了
aspect-ratio、container queries）
最常被忽略的一点：加前缀不是终点，而是起点。它只解决“能不能识别”，不解决“能不能渲染正确”。真要稳，得在真实设备上跑 layout test，而不是只信 devtools 里的 computed styles。
