用 WebAIM Contrast Checker 或 axe DevTools 输入渲染后的实际颜色值（非 CSS 变量或透明色），可快速检测是否达 4.5:1；须注意字体渲染、主题切换及禁用态等场景需单独验证。
怎么用在线工具快速检测颜色对比度是否达标（4.5:1）
直接打开 WebAIM Contrast Checker 或 axe DevTools 浏览器插件，输入前景色和背景色的十六进制值（比如 #000000 和 #ffffff），它会立刻告诉你是否满足 WCAG AA 级别的 4.5:1 要求。别信“看起来差不多”——人眼对灰阶对比极度不敏感，必须靠工具量化。
常见错误现象：rgba(0, 0, 0, 0.7) 叠在 #f5f5f5 上显示很清晰，但工具一测只有 3.8:1；或者设计师给的 #666 文字配 #eee 背景，实际对比度仅 2.9:1，完全不达标。
- 优先用
WebAIM Contrast Checker（免费、无登录、支持透明色解析） - 开发阶段集成
axe DevTools，它能在真实页面上高亮所有对比度不合规的元素 - 注意：工具默认按“正常文本”（≥18pt 或 ≥14pt 加粗）判断阈值，小字号常规文本必须严格卡 4.5:1；大标题可放宽到 3:1（AA 级）
CSS里写颜色时，哪些写法会让对比度检测失效或误判
透明度是最大陷阱。CSS 中的 rgba()、hsla()、transparent 或 backdrop-filter 后的叠加色，多数在线工具无法自动计算最终渲染色值——它们只认“静态色块”，不会模拟图层混合。
使用场景：按钮悬停态用 background-color: rgba(0, 0, 0, 0.1)，文字仍是 #333，但实际对比度取决于底层背景。此时工具输入的只是中间一层，结果毫无意义。
立即学习“前端免费学习笔记（深入）”；
- 检测前，务必先在浏览器开发者工具中复制最终渲染出的
rgb()值（右键元素 → “Computed” → 找color或background-color的 resolved 值） - 避免用
currentColor直接检测——它的实际值依赖上下文，工具无法推断 - CSS 自定义属性（
--text-color）需先手动替换为具体值再检测，工具不解析 CSS 变量
为什么 #333 在 #fff 上不总是安全？字体、粗细和抗锯齿的影响
#333 和 #ffffff 理论对比度是 12.6:1，远超 4.5:1，但实测中仍可能被读屏软件或低视力用户识别困难——问题不出在色值本身，而出在渲染细节。
性能 / 兼容性影响：Windows 上 ClearType、macOS 的子像素渲染、Chrome 的字体平滑策略，都会让细字体（如 14px font-weight: 400）的边缘灰度升高，等效降低对比度。尤其在非 Retina 屏幕上，#333 实际呈现接近 #444～#555。
- 小字号文本（≤16px）建议用至少
#222（对比度 ≈17:1）保底，别省那点灰度 - 避免在
font-weight: 300或font-smooth: antialiased下硬扛#555类浅灰 - 用
prefers-reduced-motion或forced-colors媒体查询时，对比度逻辑要单独校验——系统强制配色会覆盖你的 CSS
如何在 CSS 变量和主题切换中持续保障对比度
用 :root 定义 --text-primary 和 --bg-surface 很方便，但换主题时，不能只换两个变量——必须成对验证每种组合的对比度，否则深色模式下 #e0e0e0 文字配 #2d2d2d 背景可能只剩 3.2:1。
容易踩的坑：以为“深色模式反着来就行”，结果把浅色模式的 #333/#fff 直接换成 #ccc/#111，没重算——#ccc 在 #111 上只有 3.7:1。
- 建立最小可用对比色对表，例如：
--text-on-dark: #e6e6e6（不是随便挑个浅灰） - 用 PostCSS 插件
postcss-contrast在构建时自动校验变量组合，失败则报错 - 深色模式下慎用
inset box-shadow模拟凹陷效果——阴影会进一步降低文字区域的局部对比度
最常被忽略的一点：按钮禁用态（disabled）的颜色不是“随便变灰就行”。很多项目用 opacity: 0.5，这会同时削弱前景色和背景色，导致对比度断崖式下跌——必须单独定义禁用态的色值，并重新检测。
