Less无法实现运行时自适应文本对比度，因其contrast()函数仅支持编译期静态计算，不响应DOM背景色、CSS变量或系统偏好设置；真正自适应需依赖CSS媒体查询或JS运行时控制。
Less 本身无法实现运行时自适应文本对比度——color-contrast() 函数尚未被任何主流浏览器支持，而 Less 编译期又无法读取 DOM 背景色或响应用户系统设置。所谓“自适应”，必须拆解为「编译期静态校验」和「运行时 CSS 响应」两层，不能混为一谈。
为什么直接用 contrast() Less 函数不等于自适应
Less 的 contrast(@bg, @text, @fallback-light, @fallback-dark) 是纯静态计算：它只在编译时比对两个固定颜色值是否满足 @contrast-ratio，输出其中一个 fallback 色。它不会感知页面实际背景色（比如某个 .card 的 background-color 来自 JS 动态注入），更不会响应 prefers-color-scheme 或 prefers-contrast 媒体查询。
- 常见错误是写
@text-on-card: contrast(@card-bg, #000, #fff);，但@card-bg若是变量而非具体值（如@card-bg: var(--bg-color)），Less 直接报错 “Operation on an invalid type” -
contrast()第三、四参数不是“亮色/暗色语义”，而是“当对比不足时强制用哪个”——它不校验var(--bg-color)实际值，只按传入的字面量算 - 该函数输出的是编译后确定的颜色值，无法随系统主题切换而更新
真正能落地的对比度控制路径
分三类场景，对应不同技术选型：
-
静态组件（背景色固定，如品牌色卡片）：用
@primary+@contrast-ratio+contrast()预生成安全文本色，例如：body { color: contrast(#f7fafc, #2d3748, #ffffff, @contrast-ratio); } -
动态背景（CSS 变量注入，如
--bg-color: #e2e8f0）：放弃 Less 计算，改用构建时工具校验（如stylelint-a11y检查color与background-color对比度），或运行时 JS 读取getComputedStyle后手动设color -
系统级适配（高对比/深色模式）：纯 CSS 媒体查询驱动，
prefers-color-scheme和prefers-contrast必须显式声明，且不能依赖 Less 变量插值：@media (prefers-color-scheme: dark) { body { color: #e2e8f0; background-color: #1a202c; } }
容易被忽略的兼容性硬伤
截至 2026 年 10 月，以下事实仍成立：
立即学习“前端免费学习笔记（深入）”；
-
color-contrast()在 Chrome、Firefox、Safari 中均未实现，MDN 文档仅作草案标注，任何线上项目中使用都会静默失效 -
prefers-contrast: high不会自动加粗文字或改变字号，JS 修改font-weight无效，必须靠 CSS 中明确声明font-weight: 700和足够大的font-size - 所有基于
var(--bg)的对比度逻辑，都需配套 WCAG 公式人工复核：(L₁ + 0.05) / (L₂ + 0.05) ≥ 4.5，Less 无法代劳
最终要守住的底线是：Less 只负责把设计系统里的对比度规则固化下来，而不是假装能替代浏览器渲染逻辑或无障碍 API。真正的自适应，永远发生在 CSS 运行时或 JS 交互层，不在预处理器里。
