CSS.supports 是 JavaScript API，必须等 JS 环境就绪后才能调用，无法早于 JS 执行；真正能在 JS 运行前生效的只有 CSS 层级的 @supports 规则，它在样式解析阶段即完成条件判断并影响首次渲染。
CSS.supports 不能在 JS 运行前执行——它本身就是 JavaScript API，必须等 JS 引擎启动后才能调用。所谓“JS 运行前检测”，本质是误解了执行时序。真正能提前干预布局的，只有 CSS 层级的 @supports 规则。
为什么 CSS.supports 无法早于 JS 执行
这个函数属于 window.CSS 接口，依赖完整的 DOM 和 JS 运行环境。页面解析 HTML 时，CSS 规则（包括 @supports）会随样式表同步解析并生效；而 JS 脚本默认阻塞解析，且需先完成脚本加载、编译、执行三阶段。哪怕把 <script> 放在 <head> 最顶部，它也一定晚于 @supports 的 CSS 解析时机。
@supports 是唯一能在 JS 加载前起作用的特性检测机制
它写在 CSS 文件或 <style> 标签里，浏览器解析样式时就完成条件判断，无需 JS 参与：
- 支持时，内部样式立即参与层叠计算，影响首次渲染
- 不支持时，整段规则被忽略，不影响其他样式
- IE 系列（含 IE11）完全不识别
@supportsat-rule，直接跳过——这反而是优点：避免因语法错误导致样式表中断
示例：用 @supports 提前启用 Grid，同时保留 Flex 回退
@supports (display: grid) {
.layout { display: grid; grid-template-columns: repeat(3, 1fr); }
}
.layout { display: flex; }
注意顺序：回退样式写在前面，增强样式用 @supports 包裹在后。浏览器按层叠顺序自然覆盖。
立即学习“前端免费学习笔记（深入）”；
哪些场景下误以为需要 CSS.supports，其实该用 @supports
常见误用包括：
- 想根据容器查询支持情况动态插入 class —— 实际应直接用
@supports (container-type: inline-size)控制对应 CSS 块 - 为
gap或aspect-ratio做样式降级 —— 完全可由@supports(gap: 1rem)或@supports(aspect-ratio: 1/1)处理 - 检测
display: flex后决定是否加载 polyfill —— 但现代项目中，Flex 回退通常只需简单 display 替换（如 block），无需 JS 干预
真正需要 CSS.supports 的场合极少，典型如：
- 统计上报：记录用户浏览器对某特性的支持率
- 动态组件加载：例如只在支持
container-type的环境下才import()容器查询专用模块 - 运行时样式切换逻辑：比如用户手动开启「高级布局模式」时做二次确认
容易忽略的关键细节
很多开发者卡在语法细节上导致检测失败：
-
CSS.supports('display', 'grid')❌ 错误：第二个参数必须是完整声明值，正确写法是CSS.supports('display: grid') -
@supports (display: grid) and (gap: 1rem)✅ 正确：多个条件必须用and连接，且每个条件独立加括号 -
@supports not (display: grid)✅ 正确：not外围不需要额外括号，但嵌套时需谨慎（如@supports not ((display: grid) and (gap: 1rem))） - 检测
aspect-ratio时，Safari 15.4+ 才支持，旧版返回 false —— 但@supports规则本身仍可安全使用，不支持时自动走回退
最常被忽略的一点：检测结果为 false 并不等于「该特性完全不可用」，而只是「当前浏览器未声明支持」。某些特性（如部分容器查询行为）可能在特定上下文（如 iframe 或 shadow DOM）中表现异常，@supports 无法覆盖这类边界情况。
