结论：用caniuse.com+@supports+真实用户浏览器分布交叉验证；查前先锁定目标范围，关注仍在产生流量的版本（如Safari 15.6、Firefox 90前、Android WebView Chrome 70–80），IE可忽略；@supports须写全声明且fallback前置，清单应聚焦高频失效行为而非泛泛支持。
直接上结论：别从零写清单，用 caniuse.com + @supports + 项目真实用户浏览器分布三者交叉验证，才是可持续的排查逻辑。
查兼容性前先锁定目标浏览器范围
盲目兼容所有版本等于浪费时间。2026 年实际需要关注的不是“哪些浏览器存在”，而是“哪些版本还在产生真实流量”：
- Edge 18 及更早（EdgeHTML 内核）——虽已停用，但部分政企内网仍跑着
- Safari 15.6 及更早——iOS 15.6 设备尚未完全退出活跃用户群，
aspect-ratio、:has()在此版本有严重渲染 bug - Firefox 90 之前——
container queries直到 Firefox 111 才稳定，旧版需降级为媒体查询 - Android WebView（Chrome 70–80）——大量国产安卓 App 内嵌 WebView 卡在此区间，
gap、subgrid均不支持 - IE 已于 2022 年 6 月终止支持，除非合同明确要求，否则不投入任何兼容成本
用 @supports 替代 UA 判断和 CSS 前缀堆砌
很多人把兼容性等同于加前缀，但 autoprefixer 只补前缀，不解决特性缺失。真正可控的渐进增强靠 @supports：
- 检测必须写全声明：
@supports (color: oklch(0% 0 0))✅；@supports (oklch)❌（语法无效，整条规则被跳过） - fallback 颜色必须写在
@supports外部且在前，否则旧浏览器可能因解析失败而丢弃全部颜色声明 -
@supports不支持嵌套检测，比如不能写@supports (display: grid) and (not (gap: 1rem))，得拆成两层 - 对
color-mix()这类函数，检测时括号内必须是合法值，@supports (color: color-mix(in srgb, red, blue))才有效
建立最小可行排查项（非功能清单）
一份可维护的清单不该罗列“支持 flex 吗”，而应聚焦高频出问题的具体行为：
立即学习“前端免费学习笔记（深入）”；
-
flex: 1在 Safari 15.4–15.6 中会因min-width: auto导致内容撑开容器——固定解法是加min-width: 0或overflow: hidden -
gap在 Android WebView（Chrome 70–80）中完全无效——必须用margin模拟，且注意父子 margin 折叠 -
scrollbar-color仅 Firefox 支持，WebKit 系（Safari / 新 Edge）至今无标准方案——不要尝试 hack，改用 JS 控制滚动条显隐更可靠 -
:has()虽在 Safari 15.4+ 声称支持，但 15.4–15.6 存在选择器匹配失效、伪类嵌套崩溃等问题——生产环境建议等 Safari 16+ 或用 JS 特征检测后降级
真正难的不是知道某特性是否支持，而是判断它在某个版本里“支持但不可用”——比如 aspect-ratio 在 Firefox 89+ 原生支持，但旧版用 padding-top 百分比 hack 时，若父容器 width 动态变化，padding 计算会滞后一帧。这种细节没法靠工具自动发现，只能靠真实设备回归测试沉淀进清单。
