更稳妥、也更符合无障碍规范的做法，是直接使用 WebAIM Contrast Checker 检测浏览器真实渲染后的 resolved 颜色值，而不是手动套公式计算，或直接把设计稿中的 HEX/RGB 数值拿来判断；更具体地说，需要在 Chrome DevTools 的 Computed 面板中获取 color 和 background-color 的最终 rgb 值，这样透明度、混合模式以及页面上下文带来的影响，才能被准确纳入颜色对比度计算。
最直接的方法就是借助专业工具检测，不建议自己手算公式——人眼对灰阶对比本身就不敏感，手动计算时也很容易忽略亮度归一化、sRGB 伽马校正等关键环节，最终得到的 CSS 对比度结果往往并不准确。
用 WebAIM Contrast Checker 输入渲染后的真实色值
它免费、无需登录，并且适合在开发阶段快速进行颜色对比度检测，是非常实用的入口工具。但一定要注意：输入的不能是 rgba(0, 0, 0, 0.7) 或 currentColor 这类动态值，而必须是浏览器最终渲染出来的 rgb(34, 34, 34) 这类 resolved 值。
- 打开 Chrome DevTools → 选中目标元素 → 切换到 “Computed” 面板 → 查找
color和background-color对应的 resolved 值（右键可直接复制） - 将这两个真实色值粘贴到 WebAIM 工具中，它会立即返回对比度比例以及是否符合标准（正文文本通常需 ≥4.5:1）
- 像按钮禁用态、深色模式切换后、
backdrop-filter叠加层等场景，都必须分别单独检测——同一套 CSS 变量在不同页面上下文中渲染出的实际颜色值可能完全不同
为什么不能直接用设计师给的 HEX 或 RGB 值？
原因在于透明度、叠层和混合效果会让最终显示颜色发生明显变化。比如 background-color: rgba(0, 0, 0, 0.1) 叠加在 #f5f5f5 上，人眼看到的是浅灰色，但如果工具里只输入 rgba(0, 0, 0, 0.1)，那就完全没有把底层背景颜色的参与计算进去。
opacity会作用于整个元素（包括子元素），而rgba()只影响当前属性自身的颜色通道，两者的混合逻辑并不相同mix-blend-mode: difference这类混合模式会彻底改变最终颜色输出，WebAIM 无法直接模拟，因此必须在真实页面中截图取色，或通过 DevTools 查看 resolved 值- CSS 变量如
--text-color: #666即使在 :root 中定义，当它被color: var(--text-color)引用时，最终亮度仍然取决于父级背景是否透明、是否叠加滤镜等因素
小字号文本必须卡死 4.5:1，别信“大标题放宽到 3:1”
WCAG AA 级标准其实非常明确：常规正文（<18pt 且非粗体）必须达到 ≥4.5:1；只有 ≥18pt，或 ≥14pt 且为加粗的文本，才允许放宽到 3:1。很多团队会误把按钮文字、表单标签、卡片副标题视为“大号文本”，结果实际检测只有 3.2:1，用户一旦缩放字体，阅读体验就会明显下降。
- 使用 Chrome 的 “Rendering” 面板开启 “Emulate vision deficiencies”，可以快速预览色弱用户所看到的页面效果
- axe DevTools 插件能够自动扫描整个页面，高亮所有未达标的文本节点，并帮助定位具体 CSS 规则
- 不要依赖“肉眼看起来还可以”——灰色系组合（例如
#999文字搭配#eee背景）实测通常低于 3:1，必须通过工具进行量化验证
真正困难的并不是如何计算颜色对比度，而是如何确保每一种视觉状态（悬停、禁用、加载中、主题切换后）都能拿到准确的 resolved 色值。对于 CSS 前景色与背景色对比度检测来说，DevTools 的 Computed 面板才是最可靠的依据，其他方式基本都只是推测。
