CSS颜色表示法不影响对比度达标与否，关键在于color与background-color组合经WCAG公式计算后是否满足≥4.5:1（普通文本）或≥3:1（大号文本），所有表示法最终都归于sRGB值参与计算。
直接说结论：CSS颜色表示法本身不决定对比度是否达标，关键在于你选的color和background-color组合是否通过WCAG公式计算后满足≥4.5:1（普通文本）或≥3:1（大号文本）。十六进制、RGB、HSL甚至currentColor都能达标，也能不达标——全看数值，不看写法。
用什么颜色表示法不影响对比度，但影响可维护性
你写#333、rgb(51, 51, 51)、hsl(0, 0%, 20%)或var(--text-dark)，最终渲染出的都是同一个sRGB值，对比度计算结果完全一样。但不同表示法对团队协作和主题切换的影响差别很大：
-
hex和rgb()难调整明度，改一个色常要反复试； -
hsl()和hsla()能直观控制亮度（l参数），比如hsl(0, 0%, 20%)比#333更易理解“这是20%亮度的灰”； -
rgba()和hsla()引入透明度后，实际对比度取决于叠加后的最终色——rgba(0,0,0,0.7)叠在#f5f5f5上，工具测出来可能只有3.8:1，不是“看着像黑字就安全”； -
var(--color)配合CSS变量统一管理时，必须确保所有主题变体（如暗色模式）下，color与background-color的组合仍满足对比度，不能只测默认主题。
rgba/hsla透明色必须实测最终渲染色
透明色的对比度不是靠“前景色+背景色”简单估算出来的，浏览器会做alpha混合。例如：
.box {
background-color: #f8f8f8;
color: rgba(0, 0, 0, 0.7);
}
这段代码里文字实际渲染色接近#a9a9a9，而非纯黑或半透黑——必须把混合后的最终色值输入WebAIM Contrast Checker或axe DevTools验证。常见错误是把rgba(0,0,0,0.7)当成“深灰”目测过关，一测只有3.2:1。
立即学习“前端免费学习笔记（深入）”；
- 工具不支持直接输
rgba()，得先用在线混合工具（如https://css-tricks.com/rgba-hex/）转成十六进制； - 如果背景也是透明色（比如
background: rgba(255,255,255,0.9)），必须算两层叠加后的最终色再测； - 禁用态按钮（
:disabled）的color和background-color也要单独验证，常被忽略。
color-contrast()函数目前只能作为增强，不能替代人工校验
color-contrast()在Chrome 114+/Edge 114+/Safari 16.4+（需开启实验特性）中可用，但它不是万能钥匙：
- 语法必须带
to WCAG21/AA或to WCAG20/AA，写成color-contrast(var(--bg) vs #000, #fff)不生效； - 它只从你给的候选色里挑一个“相对最优”，但如果所有候选都不达标（比如
--bg是浅黄，候选只有黑和白），它返回黑，但黑字在浅黄上可能只有3.1:1——依然不合规； -
@supports检测必须写完整：@supports (color: color-contrast(#000 vs #000 to WCAG21/AA))，漏掉to部分会导致检测失败； - 当前无法处理渐变背景、图片背景或
filter叠加后的实际亮度，这些场景仍需JS计算或手动覆盖。
真正容易被忽略的点是：对比度验证必须在真实设备渲染后做，而不是看设计稿或开发机截图。LCD屏、低亮度设置、屏幕反光都会吃掉1–2个对比度点，所以工具测出刚好4.5:1的组合，在用户手机上很可能掉到4.1:1——建议所有关键文本留出0.3–0.5的余量。
