lighten()/darken()的百分比是HSL明度L的绝对偏移而非比例；函数仅接受color类型输入；hsl字面量在Less 3.x中不可直接调用；mix()基于RGB混合，与感知明度不一致。
lighten() / darken() 的百分比不是“亮度增减比例”，而是 HSL 的 L 分量绝对偏移
很多人写 lighten(#333, 30%) 以为是“让颜色变亮 30%”，结果得到一个发灰的浅褐，而不是中性浅灰。这是因为 lighten() 实际是在 HSL 色彩空间里，把当前颜色的 L（明度）值直接加 30 个百分点，不是乘法缩放。
- #333 的 HSL 明度约 20%，
lighten(#333, 30%)→ L = 50%，对应的是 #777 左右，但因 S（饱和度）未调整，人眼感知上偏浊 - 而 #2563eb 的 L 是 ~42%，
lighten(@primary, 30%)会冲到 72%，接近 #a0bfff —— 看似合理，但再加 10% 就溢出成 #ffffff - 链式调用如
darken(lighten(@c, 10%), 10%)不等于原色：HSL 插值非线性 + 四舍五入，结果常有 1–2% L 偏差
传入非 color 类型变量时函数静默失效或报错
lighten()、saturate() 等函数只接受 color 类型输入。一旦传入字符串、undefined 或 CSS 自定义属性，行为分两类：
- 传入带引号的字符串：
@color: "#3b82f6"→ 编译报错Error evaluating function `lighten`: color expected - 传入 CSS 变量：
lighten(var(--main-color), 10%)→ Less 编译期根本读不到运行时值，直接报错或跳过 - 传入未定义变量：
lighten(@missing, 10%)→ 报错Cannot resolve variable @missing，但若用了iscolor()守护，可降级：@safe: iscolor(@c) then @c else #000
hsl() 字面量在旧版 Less 中无法直接受函数调用
Less 4.0+ 支持对 hsl(205, 70%, 55%) 这类字面量直接套 lighten()，但 3.x 版本会报 Operation on an invalid type。这不是语法错，是类型系统限制。
- 兼容写法：先赋值给变量，再调用函数
@base: hsl(205, 70%, 55%);<br>.btn { background: lighten(@base, 8%); } - 检查版本：
lessc --version；Webpack 项目需确认less-loader封装的 Less 版本是否 ≥4.0 - 更稳妥的做法是统一用变量管理主色：
@primary-h: hue(#2563eb); @primary-s: saturation(#2563eb); @primary-l: lightness(#2563eb);，后续所有计算基于这三个值
mix() 生成的灰阶与设计稿明度值对不上
mix(white, @color, 70%) 不等于“70% 明度”，它做的是 RGB 通道加权平均，而 Figma/Sketch 使用 CIELAB 的 L* 值（感知均匀亮度）。同一数值在不同算法下视觉亮度差异可达 ±20%。
立即学习“前端免费学习笔记（深入）”；
- 想生成明度为 30% 的灰？别猜 mix 比例，先用
unit(lightness(@color), %)查目标色明度，再反推：mix(black, white, 30%)（因为 black=0%, white=100%） - 对非灰阶色慎用
mix(black, #FF6B6B, 40%)：RGB 混合会让红色通道衰减更快，结果偏棕；改用darken(#FF6B6B, 25%) + saturate(5%)更可控 - 所有
mix()结果务必在 OLED 屏上实测——低饱和深色在子像素排列下容易发虚或偏绿
实际项目里最易被忽略的，是 *HSL 明度（L）和人眼感知亮度（L）不是一回事*。你调出来的 60% L，在屏幕上可能看起来像 45% L，尤其在深色背景或广色域设备上。别只信函数返回值，打开开发者工具的颜色拾取器，点开最终渲染出的色块，看它真实的 sRGB 值和计算出的 L* 值。
