darken() 和 lighten() 函数直接增减 HSL 的 L 值（0–100%），非叠加黑白；易致高饱和色发灰、浅色失辨、深色过暗，且 Less 与 Sass 实现不一致，建议用色阶变量或 mix() 替代。
darken() 和 lighten() 函数的实际效果不是“加黑”或“加白”
很多人以为 darken(#ff6b6b, 20%) 是在原色基础上叠加 20% 黑色，lighten() 同理叠加白色——这是错的。Less 的这两个函数操作的是 HSL 色彩空间中的亮度（L）通道：它把输入颜色转成 HSL，然后**直接增减 L 值（0–100%）**，再转回 RGB。所以结果更自然，但和“混合黑色/白色”的视觉感受不同，尤其对饱和度高的颜色，加深后可能明显发灰。
实操建议：
- 用浏览器开发者工具实时调试：写好
darken(@primary, 10%)后，鼠标悬停在编译后的颜色值上，看 HSL 的 L 值是否如预期变化 - 避免跨度过大：超过 30% 容易让颜色失真，比如
darken(#00e0ff, 40%)会变成接近深青灰，而非“深青色” - 慎用于浅灰背景上的文字：例如
lighten(#333, 15%)得到的是 #5c5c5c，对比度可能不足 WCAG AA 标准
lighten() 对纯白或接近白色的处理很危险
lighten(#fff, 5%) 不会报错，但结果仍是 #ffffff——因为 L 已达上限 100%，无法再提亮。更隐蔽的问题是：lighten(#f9f9f9, 10%) 可能产出 #fcfcfc，肉眼几乎不可辨，却在 CSS 中多占了 7 字节。
常见错误现象：
立即学习“前端免费学习笔记（深入）”；
- 按钮悬停色用
lighten(@bg, 8%)，结果 hover 和 normal 看起来没区别 - 主题色生成器里批量调用
lighten()，导出的浅色系全部挤在 #fafafa–#ffffff 区间
替代方案：
- 对极浅色，改用
fadeout(@color, 5%)降低透明度（需父容器有背景色） - 固定浅色阶梯：定义
@light-1: #f5f5f5; @light-2: #eeeeee;，比依赖函数更可控
darken() 在深色模式下容易过暗甚至变黑
假设主色是 @accent: #8a2be2（中等紫），darken(@accent, 25%) 得到 #4a1784；但如果主题本身已是深色背景（如 background: #121212），这个加深色用作文字或边框时，与背景对比度过高，反而刺眼。
使用场景提醒：
- 深色 UI 中，优先考虑
saturate()或spin()调整色相/饱和度，而非一味darken() - 如果必须加深，搭配
fade()控制透明度：比如fade(darken(@accent, 15%), 90%)让颜色更柔和 - 注意 Less 编译顺序：若
@accent来自变量文件且被多次darken()嵌套调用（如darken(darken(@accent, 10%), 10%)），实际是两次独立 L 值运算，不是累计 20%
和 Sass 的 darken()/lighten() 行为不一致
Less 和 Sass 都有同名函数，但 Sass 的实现更激进：它会在 HSL 转换前先将输入颜色强制归一化，导致相同参数下，Sass 的 darken(#ff6b6b, 20%) 比 Less 版本更暗。如果你正在迁移样式库，不能直接替换函数名。
验证方法：
- 在 Less 文件中写
.test { color: darken(#ff6b6b, 20%); }，编译后查最终十六进制值 - 在 Sass 中写同等语句，对比输出——通常 Sass 版低 5–10 的亮度值
- 跨框架协作时，建议统一用
mix()函数模拟：例如mix(#000, @color, 20%)（混合 20% 黑色）行为更可预测
真正要注意的，是团队里有人习惯用 darken() 快速出稿，却没意识到它在不同主题、不同基础色下的非线性表现。与其反复调试百分比，不如提前定义好几档明确的色阶变量，把“加深”这件事从运行时逻辑变成设计约束。
