color-contrast() 不是自动检测工具，而是返回候选色中最易读颜色的 CSS 函数，需显式列出前景候选并用 against 指定背景，不校验 WCAG 标准。
怎么用 color-contrast() 检测颜色可读性
Chrome 125+ 和 Safari 18.0+ 已支持实验性 color-contrast() 函数，但它不是“自动标红警告”的检测工具，而是 CSS 运行时计算函数——你得主动调用它，并配合 color-mix() 或媒体查询做响应式 fallback。
- 它只接受两个参数：
color-contrast(<foreground>, <background>)，返回一个<color>值（不是对比度数值），即在给定背景上“最易读”的前景色（从你传入的候选列表中选） - 候选色必须显式列出，比如
color-contrast(white, black, #333, #666 against #f0f0f0)，不写against会直接报错SyntaxError: expected 'against' at position X - 它不校验 WCAG AA/AAA，只是按相对亮度差挑一个“相对最可读”的色——哪怕所有候选都低于 4.5:1，它也照常返回其中一个
calc() + relative-color-syntax 手动算对比度靠谱吗
目前没有纯 CSS 方案能输出具体对比度数值（如 7.2），calc() 无法访问颜色通道值，lch()/oklch() 色彩空间虽有明度 l，但 WCAG 对比度公式是 (L1 + 0.05) / (L2 + 0.05)（L 为相对亮度），而 CSS 无法把 lch(50% ...) 的 50% 转成线性亮度值。
- 试图用
lch(50% 0 0)当作灰度近似 L=0.218 是错的——L=50% 在 lch 中是非线性感知亮度，不是物理亮度 - 真正能算出合规对比度的，只有 JS 的
window.getComputedStyle()+getContrastRatio()（需自己实现或引入@ctrl/tinycolor等库） - CSS 自定义属性（
--bg-luminance）手动存亮度值可行，但维护成本高，且无法随主题色动态更新
PostCSS 插件生成对比度检查提示的实操边界
像 postcss-accessibility 或自定义插件可以在构建时扫描 color / background-color 对，但它只能查静态值（#333, rgb(51,51,51)），对变量、color-mix()、hsl() 动态计算完全无能为力。
- 遇到
color: color-mix(in srgb, var(--primary), white 20%)，插件直接跳过——它不执行 CSS 计算，只做字符串匹配 - 支持 CSS 变量的前提是：变量值本身是硬编码色值，且插件配置了对应作用域（比如限定
:root下的--text必须与--bg满足 4.5:1） - 误报率高：插件把
border-color: #ccc和background: white配对检测，但边框根本不算文本对比度场景，WCAG 明确只要求“文本及其背景”
真正能落地的配色方案控制点在哪
别指望 CSS 自己“发现”对比度问题，得把校验逻辑收口到设计系统源头：用 SCSS/Less 定义色板时，就用函数预计算并约束组合，比如 text-on($bg-color) 返回合规的文本色，而不是靠运行时猜。
立即学习“前端免费学习笔记（深入）”；
- 关键控制点是
background和color的绑定关系——同一组件内，--card-bg只允许搭配--card-text，这两个变量必须由同一套算法生成（如基于oklch()的 L 值区间映射） - 深色模式切换时，不能只换
background-color，必须同步更新color、border-color、icon-filter，否则color-contrast()会因背景变暗却沿用浅色文字而失效 - 最易被忽略的是半透明叠加层：比如
background: rgba(0,0,0,0.5)盖在图片上，此时对比度取决于底层图+叠加色混合后的实际背景，CSS 无法感知，必须靠设计稿标注或截图工具人工校验
