less中需自定义luma()函数计算srgb相对亮度，再结合lighten()/darken()等逼近wcag 4.5:1对比度；禁用fade()/spin()/mix()等非亮度导向函数，并确保mixin输出静态hex/rgb值以通过工具检测。
Less里怎么用颜色函数算出合规对比度
直接用 contrast() 函数不行——Less 没这个内置函数。你得靠 lighten()、darken()、desaturate() 和手动计算灰度值来逼近 WCAG 要求的 4.5:1。核心思路是：把背景色转成等效亮度（luminance），再反推文字色最小可接受亮度，最后用函数生成接近该值的颜色。
常见错误是拿 darken(@bg, 20%) 直接当文字色——它只调色相饱和度，不保对比度；尤其在浅灰背景上，结果常掉到 3.x:1。
- 先用
luma(@color)自定义函数估算相对亮度（需手动实现，基于 sRGB 转换公式） - 对深色背景，文字用
lighten(@bg, 70%)起手，再微调；对浅色背景，用darken(@bg, 60%)+saturate()补足辨识度 - 禁用
fade()或fadeout()做文字色——透明度不参与对比度计算，且编译后仍是 rgba，工具无法解析
为什么 @text-color: darken(@bg, 60%) 在暗色模式下仍可能不达标
因为 darken() 是按 HSL 模型减亮度，而 WCAG 对比度基于人眼感知的相对亮度（luminance），两者非线性。比如 @bg: #1e1e1e，darken(@bg, 60%) 得到的是 #000000，理论对比度 21:1，没问题；但若 @bg: #2d2d2d，同样操作得 #0a0a0a，实测仅 11.2:1——看似够，小字号下抗锯齿一加，边缘灰度上升，有效对比度掉到 4.3:1。
真实场景中，必须结合字体渲染效果验证：
- 小字号（≤16px）文本，建议最低用
darken(@bg, 75%)起步，再人工校验 - 避免用
spin()或mix()处理文字色——它们改变色相，易削弱灰阶差异 - 暗色模式下，别只依赖背景变深，要同步提升文字色明度差值，比如从
darken(@bg, 60%)改为mix(#ffffff, @bg, 85%)
如何让 .text-contrast Mixin 自动适配亮/暗背景并输出可检测色值
关键不是“生成好看的颜色”，而是“生成工具能准确读取的静态 hex/rgb 值”。所有带透明、变量、currentColor 的写法，都会让 WebAIM Contrast Checker 误判。
正确做法是 Mixin 输出确定的十六进制值，并在调用前完成所有运算：
- 用
unit(luma(@color), "")提取亮度数值，做 if/when 判断分支 - 分支内直接返回
#000000或#ffffff这类硬编码值，或用rgb(0, 0, 0)——确保开发者工具“Computed”面板里看到的是纯 rgb()，不是 rgba() - 禁止在 Mixin 里用
@{variable}拼接颜色，比如~"rgb(@{r}, @{g}, @{b})"，编译器不保证类型安全，容易产出非法值 - 给 Mixin 加默认参数：
.text-contrast(@bg: #ffffff, @level: aa)，其中@level: aa触发 4.5:1 计算逻辑，@level: aaa则走 7:1
@import 顺序错导致对比度样式失效的典型表现
你写了 .btn { color: .text-contrast(@bg); }，编译后却是 #333，而不是期望的 #1a1a1a——问题往往不在 Mixin 本身，而在变量作用域。
Less 变量是“就近覆盖”，不是“运行时求值”。如果主题文件（含 @bg: #121212）在组件文件之后 @import，那么 .text-contrast() 编译时看到的 @bg 还是初始值（比如 #ffffff）。
- 所有主题变量文件（如
_theme-dark.less）必须放在所有组件 Mixin 文件之前 - 验证方法：在 Mixin 内加注释
// debug: @bg = @bg，看编译后 CSS 里是否是你设的暗色值 - 不要用
!default给@bg设默认值——它只防未声明，不防后声明覆盖
最易被忽略的是：颜色运算结果依赖于输入值精度，而 Less 默认浮点精度只有 3 位。比如 luma(#1e1e1e) 和 luma(#1e1e1f) 算出来一样，导致临界背景色的判断失效。需要手动补精度或加容差判断。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
