@supports 降级失败主因是 fallback 位置错误、检测目标非法或误信支持即安全；必须用合法 CSS 声明检测，fallback 写在外部且顺序正确，IE11 等旧浏览器仅执行外部兼容样式。
直接用 @supports 写降级，90% 的失败不是因为语法错，而是 fallback 没写对位置、没选对检测目标、或误信了“浏览器支持某属性”就等于“能安全用”。它不自动切换，也不兜底——你得亲手把兼容逻辑焊死在 CSS 解析流程里。
@supports 检测必须是合法 CSS 声明，不是任意字符串
浏览器只认标准属性 + 合法值的组合，其他全静默忽略，不报错、不警告、不执行内部样式。很多人写 @supports (min-width: 768px) 或 @supports (--primary: #000)，结果整块规则消失，旧新浏览器都看不到任何效果。
-
@supports (display: grid)✅ 合法：属性名和值都符合规范 -
@supports (color: oklch(60% 0.2 240))✅ 合法：oklch 是已支持的颜色函数，且作为 color 的值出现 -
@supports (color-mix(in srgb, black, white))✅ 合法：完整调用形式，Chrome 117+/Firefox 119+ 支持 -
@supports (container-type: inline-size)✅ 合法：唯一被所有现代容器查询支持者识别的语法 -
@supports (var(--x))❌ 非法：var()不是独立属性，不能单独检测 -
@supports (aspect-ratio: 1/1)⚠️ Safari ≤12.1 返回 true 但渲染异常，慎用于关键布局
fallback 必须写在 @supports 外部，且顺序不可颠倒
CSS 是从上到下解析的。旧浏览器遇到不认识的值（如 oklch()、color-mix()）会跳过整条声明；如果 @supports 块在前、fallback 在后，部分 Chrome 111 之前版本和 Android WebView 会连 fallback 行也跳过，导致无颜色渲染。
- ✅ 正确顺序：
background-color: #4a5568;→ 再写@supports (color: oklch(0% 0 0)) { background-color: oklch(60% 0.2 240); } - ❌ 错误顺序：把
@supports块写在第一行，fallback 放第二行 - IE11 完全忽略
@supports块，但它能读取外部 fallback —— 前提是那行声明独立、未被包裹、语法兼容（比如不用gap，改用margin） - fallback 颜色只能用
#rrggbb、rgb()、rgba()、hsl()、命名色；带透明度必须用rgba()，不能用 hex + alpha
@supports not 不是降级开关，IE 根本不进这个分支
@supports not (display: grid) 在 IE11 中不会触发 fallback，因为 IE 连 @supports 规则本身都不解析，整块被丢弃。你以为写了降级，其实旧浏览器根本看不到那行代码。
立即学习“前端免费学习笔记（深入）”；
- 真正生效的降级，永远是写在
@supports块外部的那部分样式 -
@supports not只对支持@supports但不支持目标特性的现代浏览器有效（如 Safari 15.6 对gap） - 想覆盖 Android 4.4 WebView？别指望
@supports not，它连规则都解析不了；只能靠“外部 fallback 语法兼容 + 无新特性干扰”硬扛 - 不要混用 JS 注入和
@supports：加载顺序不确定，CSS 解析完后 JS 才执行，容易覆盖或漏掉
复杂点不在检测，而在 fallback 是否干净退出
检测 display: grid 很容易，难的是让 float 或 flex 降级在所有目标环境里稳定生效。Safari 10.1 认 display: grid 却不支持 gap，Android 4.4 WebView 忽略整个 @supports 块，IE11 直接跳过——这些场景下，fallback 要么被覆盖、要么语法报错、要么布局错位。
真正卡住人的，是 subgrid 轨道对齐、gap 和 margin 的叠加、container 查询中父容器未设 container-type 导致规则完全不触发……这些都不是 @supports 能自动解决的。它只负责分流，后续每一条 fallback 样式，都得手动验证是否在目标浏览器中“真·起作用”。
