lighten() 和 darken() 不可靠——仅线性调整 hsl 的 l 值，不协调 s/h，易致深色发黑、浅色发灰、高饱和色失真；安全方式是拆解 hsl 分量并协同调节饱和度。
直接用 lighten() 和 darken() 生成颜色阶梯不可靠——它们只线性调整 HSL 的 L 值，不协调饱和度与色相，极易导致深色发黑、浅色发灰、高饱和色失真。
为什么 lightendarken 生成的阶梯看起来“脏”或“平”
这两个函数不是“加白/加黑”，而是对 HSL 中的亮度通道做固定百分点增减。比如 lighten(#4A90E2, 20%) 把 L 值从约 55% 提到 75%，但饱和度没变，结果就是苍白、乏力的蓝；对 #8a2be2（紫）连用两次 darken()，可能直接压成接近 #000 的浊色，而非有层次的深紫。
- 极暗色（
lightness() ）调 <code>darken()一步就到黑，文字不可读 - 极亮色（
lightness() > 85%）调lighten()几乎无变化，或直接跳成#ffffff - 传入带 alpha 的颜色（如
rgba(0,0,0,0.5)）会触发Operation on an invalid type编译错误 -
lighten(lighten($c, 10%), 10%)≠lighten($c, 20%)，中间色的 HSL 已变，非线性叠加
怎样安全地批量生成可维护的颜色阶梯
硬写 lighten(@primary, 10%)、lighten(@primary, 20%)… 很快失控。真正可控的方式是拆解 HSL 分量再组合：
- 先提取基础值：
@h: hue(@primary); @s: saturation(@primary); @l: lightness(@primary); - 浅色阶梯：升
@l同时微降@s（-2% ~ -5%），防刺眼，例如hsl(@h, @s - 3%, @l + 12%) - 深色阶梯：降
@l同时微升@s（+3% ~ +8%），避免发灰，例如hsl(@h, @s + 5%, @l - 15%) - 用
unit(@l, %)确保数值带单位，否则参与calc()会出错
什么时候该换 mix() 而不是死磕 lighten/darken
当你要的是视觉上更柔和、更中性的过渡，尤其是生成灰阶或背景层时，mix() 比 lighten() 更稳：
- 生成中性灰阶优先用
mix(@color, white, 30%)，不是lighten(@color, 30%)，尤其对深蓝、深紫 - 模拟“半透明白罩层”效果，
mix(white, @color, 20%)比lighten(@color, 20%)更贴近设计工具行为 - 注意：
mix(black, @color, 40%)对红/橙系易偏棕，此时应改用darken(@color, 15%) + saturate(@color, 5%) - 别在
mix()里混入rgba()—— Less 解析不了 alpha 通道，直接编译失败
递归 mixin 生成阶梯 class 的关键守卫条件
Less 不支持原生 for 循环，靠递归实现时，漏掉守卫就会无限编译报错：
- 必须写
.steps(@i: 1) when (@i 这类 <code>when条件，否则.steps()会一直调自身 - 用
extract()取列表项，slice()截剩余项，别用length()做唯一判断——空列表时length()返回 0，但extract(@list, 1)会报错 - 所有颜色变量（如
@primary）必须在 mixin 定义前声明，否则输出box-shadow: ;这类空值 - 方向值（如
@direction）必须转义：~"to bottom"，不能写成"to bottom"，否则 CSS 里出现引号，浏览器忽略整条规则
最易被忽略的点是：你写的 lighten() 结果是否真被设计系统认可？它和 Figma 里“亮度+20%”不是一回事，也不等价于 WCAG 对比度要求。别依赖函数名直觉，用 luma() 算亮度值、用 contrast() 辅助判断、最终靠人眼+开发者工具校验。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
