lighten()和darken()基于HSL亮度通道线性调整，易因原始色L值触边界而失真；应先查L值、控步长≤10%、避高饱和色，或改用mix()、saturate()+lighten()组合更安全。
less 中的 lighten() 和 darken() 怎么用才不翻车
这两个函数看似简单，但直接套用常导致色阶断裂或对比度崩坏。核心问题在于：它们按 HSL 的 L（亮度）通道做线性增减，不是按人眼感知调整。比如对一个深蓝 #0a2b5c 用 lighten(@color, 20%)，结果可能发灰、失饱和，而不是“更浅的蓝”。
实操建议：
- 优先用
fadeout()或fadein()控制透明度来模拟明暗变化，视觉更自然（尤其用于背景/遮罩） - 若必须调亮/调暗，先用
saturate()补一点饱和度，例如：lighten(saturate(@base, 10%), 8%) - 避免对已很亮（L > 90%）或很暗（L
用 mix() 构建可预测的渐变色阶
mix(@color1, @color2, @weight) 是构建调色板最稳的方式——它按指定权重混合两种颜色的 RGB 值，结果可控、过渡平滑。比反复套用 lighten() 更适合生成 5–7 级主色阶梯。
常见错误：把 @weight 当成“加多少”，其实它是 @color1 占比（0–100%）。想让基础色占 70%，就写 mix(@primary, white, 70%)，不是 mix(@primary, white, 30%)。
立即学习“前端免费学习笔记（深入）”；
示例（生成浅色系按钮组）：
@primary: #2563eb; @primary-10: mix(@primary, white, 90%); @primary-30: mix(@primary, white, 70%); @primary-50: mix(@primary, white, 50%); @primary-70: mix(@primary, black, 30%); // 换成 black 得到深色变体
为什么 contrast() 函数在主题切换时总失效
contrast() 本意是根据背景色自动选白或黑文字色，但 Less 编译时无法感知运行时主题状态，所以它只在编译期计算一次。如果你用变量控制深/浅模式（如 @theme: dark），contrast(@bg) 不会随 @theme 变化重算。
正确做法是手动定义两套对比色：
- 声明
@text-light: #1e293b;和@text-dark: #f1f5f9; - 用条件逻辑（
if()+lightness()）判断单个色值明暗：if(lightness(@bg) > 50%, @text-light, @text-dark) - 避免对动态注入的 CSS 变量（如
var(--bg)）使用contrast()—— Less 根本读不到它的值
导出调色板到 CSS 自定义属性的坑
Less 编译后生成的是静态 CSS，没法把 @primary-30 这类变量直接变成 --primary-30 自定义属性。很多人写 :root { --primary-30: @primary-30; }，结果发现 JS 里 getComputedStyle 读出来是空字符串。
原因：Less 默认不会把带连字符的变量名转义为合法 CSS 属性名；更关键的是，如果 @primary-30 是嵌套作用域里的变量（比如在 .theme-dark { ... } 块内定义），它根本不会出现在 :root 下。
安全导出方式：
- 所有要暴露的调色板变量统一放在顶层作用域
- 用
~"..."避免引号包裹：--primary-30: ~"@{primary-30}"; - 如果需支持 JS 动态读取，额外补一句
data-theme="light"到 html 标签，并用对应选择器覆盖变量
复杂点在于，调色板不是越全越好——导出 20 个色值会让 CSS 体积膨胀，且多数 UI 元素其实只用 3–5 个关键色阶。先定好语义命名（@color-surface-low 而非 @blue-100），再决定哪些必须进 CSS 变量。
