没有纯CSS方案能自动检测对比度是否达标，所有检测均依赖外部工具或JS运行时计算；color-contrast()不是检测函数，calc()无法计算亮度比值，浏览器DevTools显示的对比度数值源于渲染后调用无障碍API执行WCAG算法得出。
没有纯 CSS 方案能自动检测对比度是否达标，所有“检测”都依赖外部工具或 JS 运行时计算。 color-contrast() 不是检测函数，calc() 算不出亮度比值，浏览器 DevTools 显示的数值也不是 CSS 自己算出来的——它背后调用的是渲染引擎的无障碍 API。
Chrome DevTools 里悬停色块显示的对比度怎么来的
这是浏览器在渲染完成后，对实际生效的 color 和 background-color 值（已解析变量、叠加 opacity、应用 filter 后）调用 WCAG 算法得出的结果，不是 CSS 解析阶段的行为。
- 必须选中真实文本节点（比如
<p></p>或<h2></h2>），不能只看类名或变量定义 - 如果颜色来自继承或伪元素，悬停会标出
(computed)，得手动查父级或::before的getComputedStyle - 遇到
rgba(255,255,255,0.9)叠在深色父容器上，DevTools 显示的仍是“半透明白底”，但实际视觉对比可能极低——此时要自己算叠加后的真实背景色再测
Lighthouse 报 Insufficient color contrast 怎么定位真因
Lighthouse 检查的是 DOM 渲染快照，但它不会执行 JS 动态改色逻辑，也不理解 CSS 变量运行时取值，所以报错点常有误导性。
- 先点开报错项里的
node path（如div.card > span.price），在 Elements 面板里精准选中该节点 - 打开右侧
Accessibility标签页，勾选Show contrast ratio，确认当前渲染态下的数值 - 重点检查：该节点是否含
::before/::after且content非空？是否被父级opacity: 0.8或filter: brightness(0.7)影响？ - 若用
color-mix(in srgb, var(--text), transparent 30%)，Lighthouse 直接跳过——它只认硬编码色值
命令行和插件检测时最容易忽略的三个前提
所有外部工具（axe-cli、contrast-cli、WebAIM Checker）都只接受确定的十六进制或 RGB 字符串，无法处理动态色值。
立即学习“前端免费学习笔记（深入）”；
- 输入前必须确认是「最终渲染色」：把
hsl(210, 100%, 40%)转成#0066ff，把color-mix(in oklch, oklch(30% 0.2 270), white)手动算出近似 HEX - 禁用态（
:disabled）、悬停态（:hover）、暗色模式（@media (prefers-color-scheme: dark)）需单独导出颜色再测，不能只测默认态 -
border-color和outline-color不参与文本对比度校验，但部分插件会误报——WCAG 只约束color与直接包裹它的background-color
真正可控的落地点：把校验收口到预处理器或设计系统源头
指望 CSS 自己发现问题不现实。可靠做法是在 Sass/Less 编译期就拒绝低对比组合，或用 JS 在加载时批量校验关键节点。
- Sass 中可用
contrast-ratio($fg, $bg)函数（需引入compass或自定义），编译时报错而非上线后才发现 - 用
@ctrl/tinycolor写一个启动检查脚本，在DOMContentLoaded后遍历所有[role="heading"], p, li，对getComputedStyle(el).color和getComputedStyle(el).backgroundColor实时算比值 - 避免在 CSS 中写
--text: #666; --bg: #f8f9fa这类松散变量，改用语义化组合：--text-on-light: #212529; --text-on-dark: #dee2e6，从源头隔离风险
最常被绕过的环节是：没人去测 opacity 叠加后的实际对比度，也没人验证暗色模式下 prefers-color-scheme 切换后是否仍达标——而这两处恰恰是 Lighthouse 最容易漏检、用户最常投诉的地方。
