contrast()函数返回一个CSS颜色值（如#000或#fff），依据背景色明度自动选择深或浅的候选色，而非计算WCAG对比度数值；它不校验可访问性标准，仅作亮度粗略估算，需配合lighten()/darken()微调以提升实际可读性。
contrast() 函数到底返回什么颜色
contrast() 是 Less 内置的颜色对比函数，它不计算数值对比度（比如 WCAG 的 4.5），而是根据传入的背景色，自动选择 lighten() 或 darken() 后的文本色，目标是让文字在该背景下“看起来够清晰”。它的返回值永远是 **一个 CSS 颜色值**（如 #000 或 rgba(255,255,255,0.9)），不是数字，也不能直接用于条件判断。
典型用法：color: contrast(#333, #fff, #000); 表示：背景是 #333 时，优先用 #fff 作文字色，如果 #fff 在 #333 上不够显眼（实际是看亮度差是否足够），就退回到 #000。注意：Less 并不真正做可访问性校验，它只按内部亮度公式粗略估算——所以结果有时不符合 WCAG 标准。
为什么 contrast(#000) 返回白色却不可靠
当只传一个参数，如 contrast(#000)，Less 默认使用 lighten(#000, 100%)（即 #fff）和 darken(#000, 100%)（即 #000）作为候选，再选一个“更反差”的。但纯黑 #000 的亮度极低，函数直接返回 #fff；而纯白 #fff 则返回 #000。问题在于：
- 它不考虑 alpha 通道——
contrast(rgba(0,0,0,0.8))会被先转成 RGB 等效色再计算，结果可能意外 - 它对灰阶色（如
#888）的判断很保守，常返回#000，哪怕#fff其实更可读 - 无法指定最小对比度阈值，比如强制要求 ≥ 4.5:1
如何配合 lighten()/darken() 手动控制对比强度
想更可控，别只依赖 contrast() 单函数。常见做法是用 lightness() 获取背景亮度，再按需偏移：
立即学习“前端免费学习笔记（深入）”；
@bg: #2c3e50; @bg-lum: lightness(@bg); color: if(@bg-lum > 50%, #333, #eee); // 亮度高用深灰，低用浅灰
或者叠加 darken()/lighten() 做微调：
-
contrast(@bg, lighten(@bg, 60%), darken(@bg, 60%))—— 把默认的黑白候选换成更柔和的亮/暗版本 - 对按钮等组件，可封装为带 fallback 的混合：
.text-on-bg(@bg) { color: contrast(@bg, #fff, #222); }
注意：lighten(@color, 20%) 是按 HSL 调整明度，比简单改 rgb() 更符合人眼感知。
对比度不足时的实际表现与规避方式
最常踩的坑是：在浅灰背景（如 #f5f5f5）上调用 contrast(#f5f5f5) 得到 #000，但实际文本在高光屏上灰度接近，可读性差。浏览器 DevTools 里看 computed color 是 rgb(0, 0, 0)，但没告诉你对比度只有 ~2.3:1。
解决思路不是换函数，而是换策略：
- 对 UI 中关键文本（标题、表单标签），避开依赖
contrast()，直接定义语义变量：@text-primary: #212529; - 用 PostCSS 插件（如
postcss-contrast）或构建时脚本，在 CSS 输出前校验并警告低对比度组合 - 若必须动态生成，把
contrast()当作起点，再用saturate()或spin()增加色相差异，提升识别度
Less 的 contrast() 是个快速原型工具，不是可访问性保障。真要合规，得在设计系统层面对背景/文本配对做约束，而不是指望一个函数兜底。
