WCAG对比度是文本与背景亮度比值的数学标准，普通文本需≥4.5:1，大号/加粗文本≥3:1；低于此值将影响色觉障碍或弱视用户阅读，须通过相对亮度精确计算，不可仅凭视觉判断。
什么是 WCAG 对比度，为什么 color 和 background-color 不能随便配
对比度不是“看着顺眼就行”，而是有明确数学定义的：WCAG 标准要求文本与背景的亮度对比比值 ≥ 4.5:1（普通文本），大号文本或加粗文本可放宽至 3:1。低于这个值，色觉障碍用户或弱视用户可能根本读不出文字。
常见错误是直接用设计师给的 HEX 值硬套，比如 #999 文字配 #fff 背景，实际对比度只有 2.8:1；又或者用 hsl(200, 100%, 50%) 蓝配 hsl(200, 100%, 95%) 浅蓝，看似有差别，但亮度太接近，算法算出来只有 1.6:1。
真正起作用的是相对亮度（relative luminance），它由 RGB 各通道非线性转换后加权得出，和人眼感知更接近——所以不能靠调饱和度或色相来“假装有对比”。
怎么快速验证当前颜色组合是否达标
别手动算公式。用浏览器开发者工具最直接：
立即学习“前端免费学习笔记（深入）”；
- 在 Elements 面板选中文字元素，右侧 Styles 里找到
color和background-color，悬停其色块 → 会显示对比度数值（Chrome/Edge 111+、Firefox 120+ 支持） - 如果没显示，装一个轻量插件：
axe DevTools或Color Contrast Analyzer，一键扫当前页面所有文本节点 - 命令行党可用
contrast-cli：运行npx contrast-cli #333 #eee立刻返回对比度和是否合规
注意：必须测「渲染后的最终颜色」。如果用了 opacity、rgba() 半透、或父级有 filter: brightness()，要先算出叠加后的实际 RGB 再测，否则结果无效。
调整对比度的三种可靠方法（按推荐顺序）
优先改背景，其次调文字深浅，最后才动色相——因为亮度差最直接影响对比度：
-
降背景亮度：把
#f8f9fa换成#f1f3f5，往往比把文字从#495057加黑到#343a40更有效且柔和 -
用
lab()或lch()直接控亮度：比如lch(30% 50 280)是暗紫，lch(90% 5 280)是极浅灰紫，色相一致但亮度拉开，对比度自然上来；而hsl()调lightness在某些色相下会意外失饱和，导致灰蒙蒙 -
避免“安全色”陷阱：不要迷信
#000/#fff组合——纯黑背景易致眩光，纯白文字在 OLED 屏上发虚。实测#121212+#e0e0e0对比度 15.2:1，观感更稳
响应式场景下怎么保持对比度不崩
暗色模式切换、用户系统偏好变更、甚至夜间自动变暗，都可能让原定对比度失效：
- 用
@media (prefers-color-scheme: dark)时，别只改background-color，同步调color——比如亮色模式用#212529文字配#f8f9fa，暗色模式就得换成#dee2e6配#343a40，而不是沿用同一套文字色 - 慎用
currentColor：如果父容器背景随主题变，子元素用color: currentColor可能导致文字和背景同色（比如按钮内图标继承了文字色，而文字色刚好和按钮背景相近） - 动态主题 JS 控制时，别只改 CSS 变量值，要用
window.matchMedia监听变化，并重新触发对比度校验逻辑（尤其当变量参与 calc() 计算时）
最常被忽略的是图片背景上的文字——CSS 无法自动适配，必须加半透遮罩层或使用 mix-blend-mode: difference 辅助，但后者兼容性有限，得 fallback。
