在 Sass 中，lighten() 只是对 HSL 模型里的 L 值做线性提升，并不会参考人眼对亮度的真实感知，因此很容易出现发灰、失真、溢出甚至看起来“没有变化”的情况；对于极亮色、极暗色以及高饱和颜色尤其不稳定，rgba 的透明度也会在计算时丢失。并且从 Dart Sass 3.0 开始，lighten() 已被正式标记为弃用，实际开发中更建议使用 mix(white, $color, 20%) 或 color.adjust() 来替代。
lighten() 调整的是 HSL 的 L 值，并不等于视觉上的真实变亮
lighten() 的工作方式，是先把颜色转换为 HSL，再仅对 L（亮度）通道进行线性增加。比如 lighten(#0a2b5c, 30%)，会把原本大约 18% 的 L 值直接加到 48%，但这个过程并没有考虑人眼对不同色相和明暗的感知差异。所以最终结果常常不是自然提亮，而是容易出现发灰、偏青、层次变差等问题。特别是蓝色、红色、紫色这类视觉上本来就偏“深”的颜色，使用 Sass 的 lighten() 后，往往不是单纯变亮，而是颜色表现异常、失真更明显。
极值颜色和高饱和颜色使用 lighten() 容易失效或溢出
在实际 CSS / Sass 调色过程中，lighten(#fff, 10%) 依然还是 #fff，而 darken(#000, 15%) 也仍旧是 #000，原因在于 HSL 的 L 值已经达到上下边界，继续调整也不会产生变化。再例如 #ff6b6b 这种高饱和的珊瑚红，执行 lighten($color, 20%) 后，本质上是强行把 L 值继续拉高，结果往往会让饱和感被削弱，颜色显得发脏、不通透。如果原始 L 值本身已经接近 85%，再增加 20% 就会超过 100%，这时 Sass 会直接截断到 100%，最终结果可能直接变成 #ffffff。这也是很多人觉得 Sass 中 lighten() 颜色变化“不符合预期”的重要原因。
rgba 颜色在 lighten() 计算前会先丢失透明度
当你写 lighten(rgba(0, 0, 0, 0.5), 10%) 时，Sass 实际上会先把它按不透明的 #000 来处理，因此结果仍然是 #000；也就是说，alpha 透明度信息会在转换阶段被直接忽略。如果你希望在保留透明度的同时实现提亮效果，就需要额外手动组合，例如：transparentize(lighten($color, 10%), 0.5)。不过要注意，这并不代表 lighten() 支持处理 alpha，而只是后续再把透明度补回去，因此在处理半透明颜色时并不算理想方案。
新版 Dart Sass 已弃用 lighten()，推荐使用更稳定的替代方案
从 Dart Sass 3.0 开始，lighten() 与 darken() 都会触发 Deprecation Warning [color-functions]: lighten() is deprecated，后续版本中还会被移除。因此，在新的 Sass 项目或需要长期维护的 CSS 工程里，已经不建议继续使用这类旧颜色函数。官方更推荐采用模块化方式：先引入 @use "sass:color"，再使用 color.adjust() 来做颜色调整；如果你更在意结果稳定、跨颜色表现可预期，那么使用 mix(white, $color, 20%) 往往更稳妥。因为这种写法不依赖 HSL 的 L 值运算，对不同颜色的处理更一致，也不存在 lighten() 被弃用带来的兼容与维护风险。
