判断CSS属性是否被真实支持，需结合@supports检测、browserslist配置验证、DevTools中invalid提示分析及第三方库兼容策略，而非仅依赖caniuse.com。
样式兼容性问题不是“浏览器版本太老”，而是 CSS 规则在不同环境下的解析结果不一致——比如 display: grid 在旧版 Safari 里被忽略，gap 在 IE 完全无效，或者 font-feature-settings 的语法在 Chrome 和 Firefox 中略有差异。解决的关键是控制“谁生效、何时生效、为何失效”。
怎么判断某个 CSS 属性是否真被支持
别只查 caniuse.com，得看它在你真实目标环境中的行为：
- 用
@supports包裹规则：@supports (display: grid) { .grid { display: grid; } }，而不是直接写.grid { display: grid; } - 对关键降级路径（如 Flex fallback 到 Float）要显式写出，不能依赖“浏览器自动回退”
- 检查构建工具是否启用了 PostCSS 的
autoprefixer，并确认其browserslist配置匹配你的实际支持范围（例如"> 0.5%, not dead"不等于“支持 IE11”） - 在 DevTools 的 Styles 面板里，不生效的属性会显示为灰色并带“invalid”提示——点开它，能看到具体不支持的原因（如 “Not supported in this browser” 或 “Invalid value”）
第三方库的 CSS 兼容性怎么兜底
像 Bootstrap、Ant Design 这类库自带的兼容处理常被忽略，但它们的输出已做大量适配；强行覆盖反而破坏原有逻辑：
- 不要重写
.btn的display或box-sizing，优先用库提供的变体类（如 Bootstrap 的.btn-lg、Ant Design 的type="primary"） - 若必须定制，用更高 specificity 覆盖，而非改原始属性值：比如 Ant Design 的
.ant-btn已设line-height: 1.5，你要调成1.4，就写.my-app .ant-btn { line-height: 1.4; }，避免直接写.ant-btn { line-height: 1.4 !important; } - 留意库的构建产物是否含“legacy”版本（如
antd/dist/antd.compact.css），它通常已内置 IE 兼容方案，比自己手写 polyfill 更可靠 - 禁用库的某些特性时（如关闭 Bootstrap 的
$enable-transitions），要同步删掉相关 CSS 输出，否则残留动画规则可能在不支持的浏览器中报错或卡顿
自定义样式在多环境渲染不一致怎么办
常见现象是开发机看着正常，测试机字体发虚、圆角变直角、阴影消失——这往往不是兼容性问题，而是渲染上下文缺失：
立即学习“前端免费学习笔记（深入）”；
-
rem单位依赖根元素font-size，但某些 WebView（如微信 iOS）会重置html的默认字号，导致所有rem偏移。解决方案：用 JS 动态设置document.documentElement.style.fontSize，或改用vw+clamp() -
background-clip: text在 Safari 需加-webkit-background-clip: text，且必须配合-webkit-text-fill-color: transparent才生效，漏任一都失败 - CSS 变量（
--color-primary）在 IE 完全不支持，但若只用于非关键装饰（如 hover 背景色），可用color: #007bff;降级，无需 JS 检测 - 字体加载失败时，
font-display: swap能保证文本可见，但部分安卓低版本 WebView 忽略该属性，需搭配@font-face中的local()声明兜底系统字体
真正容易被忽略的，是“兼容性”和“一致性”的区别：前者关注“能否运行”，后者关注“是否看起来一样”。很多问题其实出在环境配置（如字体栈、DPR 设置、user agent stylesheet 差异），而非 CSS 本身。调试时先锁定是渲染差异还是解析差异，再决定是加前缀、换单位，还是换策略。
