@supports 不检测颜色对比度，仅判断浏览器是否支持特定css特性；它不能自动生成合规配色，但可检测color-mix()或filter: contrast()等现代特性以有条件启用增强方案。
@supports 本身不检测颜色对比度，也不能直接“为颜色定义安全色”——它只判断浏览器是否支持某个 CSS 声明能否被解析和应用。所谓“对比度安全色”，本质是 WCAG 可访问性要求（如 color 与 background-color 的亮度差需 ≥ 4.5:1），这需要计算，不是渲染引擎原生能力。因此，不能靠 @supports 自动推导或生成对比度合规的颜色组合。
但你可以用 @supports 检测 支持对比度计算的现代 CSS 特性，从而有条件地启用更精准的可访问性方案。关键在于：哪些新特性真能帮到对比度控制？
检测 color-mix() 是否可用 —— 真正可控的动态调色基础
color-mix() 是目前唯一能在 CSS 中原生混合、明暗调节颜色的函数，可用于按需生成满足对比度的文本色或背景色。但它在 Safari 16.4+、Chrome 111+、Firefox 119+ 才稳定支持。
错误写法：@supports color-mix(black, white)（语法非法，@supports 不接受函数调用）
正确写法：@supports (color-mix(in srgb, black, white))（必须是完整声明对，哪怕没实际属性名）
- 这个检测实际验证的是“浏览器能否解析
color-mix()函数语法”，不是运行结果 - 只要括号内是合法的
color-mix调用形式，就代表该引擎支持该函数 - 不支持时，整个
@supports块被忽略，回退到预设的静态配色
@supports (color-mix(in srgb, black, white)) {
.btn {
/* 用 color-mix 动态压暗背景，确保文字始终可读 */
background-color: color-mix(in srgb, #007bff, black 20%);
color: white;
}
}
检测 contrast() 滤镜是否支持 —— 快速视觉增强，非语义替代
filter: contrast(1.2) 这类滤镜能提升元素内部对比度，但它是视觉后处理，不改变语义层级或真实颜色值，**不能替代 WCAG 要求的原始色值对比度**。不过对部分弱视用户有辅助价值。
检测必须写成完整声明：@supports (filter: contrast(1))，不能省略值或括号
- Chrome/Edge 104+、Firefox 107+ 支持；Safari 目前仍不支持（截至 2026 年 5 月）
- 它不影响
color和background-color的实际计算值，仅渲染层增强 - 别把它当“自动合规开关”——通过 WCAG 检测工具跑分时，它不会让不合格的原始配色变合格
为什么 @supports (color-scheme: dark) 不能用于对比度决策
color-scheme: dark 控制的是系统级颜色偏好，不是颜色值本身。它既不提供对比度数值，也不触发任何自动调色逻辑。
- 即使检测通过，
html { color-scheme: dark }也只是告诉浏览器“我愿意适配深色模式”，后续所有颜色仍需你手动定义 - 常见误用：以为写了
@supports (color-scheme: dark) { :root { --text: #fff; } }就解决了对比度问题——错，#fff在浅色背景下对比度为 1:1，完全不可读 - 真正要做的，是在
@supports块里配合prefers-color-scheme媒体查询，分别定义深/浅色下的高对比配色
最易被忽略的落地细节：降级不是“不生效”，而是“必须显式声明”
@supports 块外的样式永远生效；块内样式只在条件为真时覆盖。这意味着：
- 你不能只写
@supports (...) { .text { color: #1a1a1a; } }就指望它在不支持时自动变浅——必须在外层先定义一个保底色，比如.text { color: #333; } - 对比度合规的关键路径永远是：先定基线（如 WCAG AA 要求的最小对比度），再用现代特性优化，而不是依赖
@supports“兜底” - 所有
@supports检测都发生在 CSS 解析阶段，无法响应运行时颜色变更（比如 JS 动态改background-color后的对比度重算）
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
