在 CSS 同色系配色中，必须只调整 lightness。因为人眼对明暗变化最敏感，固定 --h 和 --s，才能确保所有颜色都落在同一条视觉灰阶轴上，避免跳色、偏紫，并让对比度更容易控制；如果改动 hue 或 saturation，往往会导致颜色泛粉、失真、失色，甚至让整套配色逻辑断链。此外，Safari ≤15.4 还会静默忽略 hsl() 中的 calc() 计算。
只有调整lightness，并固定--h与--s，才能生成真正稳定、可维护且不发灰的同色系配色方案。原因在于，人眼对明暗层次的感知最强；当 --h 和 --s 保持一致时，只调节 lightness，所有颜色都会分布在一条视觉连续的“灰阶轴”上。这样不仅不会出现跳色、偏紫等问题，文本与背景的对比度也更容易掌控。相反，如果改动 saturation，或在 hsl() 中混用 calc() 计算明度，就可能在 Safari ≤15.4 中被静默忽略，或者造成对比度失衡、切换主题时整套 CSS 变量失去关联。
为什么必须只改 lightness，不能碰 hue 或 saturation
人眼对明暗变化最为敏感。在相同的 --h 和 --s 条件下，仅调整 lightness，所有颜色都会沿着一条视觉连贯的“灰阶轴”变化，因此不容易出现跳色、偏紫等问题，文字对比度也更容易保持稳定。然而，一旦同时修改 saturation，例如把悬停状态写成 hsl(calc(var(--h) + 5), calc(var(--s) - 10%), var(--l))，高饱和蓝色就可能瞬间泛粉，在浅色背景下甚至会让文字变得难以阅读。
常见错误现象：
--color-primary-300是#c2e9ff，--color-primary-700是#0288d1，但更换主色后才发现它们根本不在同一色相环上——因为这两个值是手工挑选的，并非基于同一个基础色推导出来- 写成
color: hsl(200, 70, 60)（缺少%）→ 整条 CSS 声明会被直接忽略，浏览器通常既不报错，也不给提示 - 混用
hsl(0, 70%, 60%)和hsl(360, 70%, 60%)→ 虽然视觉上接近，但 CSS 解析时会视为不同值，变量计算可能因此出现异常
怎么安全地用 calc() 推导明度值
Safari ≤15.4（包括 iOS 15.4）会静默忽略 hsl(var(--h), var(--s), calc(var(--l) + 10%)) 这一类写法，结果就是整条样式直接失效，并回退到继承颜色或透明状态——而你通常很难第一时间发现问题出在哪里。
更安全的做法，是先把计算结果固化为独立变量：
- 在
:root中预先定义：--l-primary-dark: 40%、--l-primary-light: 85% - 在具体样式里直接引用：
background-color: hsl(var(--h-primary), var(--s-primary), var(--l-primary-dark)); - 深色背景上的亮色变体：可使用
calc(var(--l-base) - 25%)，但下限要严格控制在15% - 禁用态：可使用
calc(var(--l-base) + 30%)，同时上限建议封顶在92%
lightness 取值有哪些硬约束
lightness 并不是可以随意拖动的参数，它会直接影响颜色可访问性、界面层次感以及实际渲染效果：
- 低于
12%：高饱和蓝色或绿色容易失去色相特征，看起来更像黑灰，尤其是在 OLED 屏幕上更明显 - 高于
92%：颜色容易泛白、刺眼，WCAG 文本对比度也经常会跌破 4.5:1 - 推荐实用区间：
15%–92%；主色明度建议控制在40%–70%之间，以便保留上下调节空间 - 禁用态如果只提高
lightness，通常会显得发灰，建议同时把saturation降到20%–30%
真正困难的地方，不是单独写对一行 hsl()，而是确保所有衍生颜色都从同一个 --h 和 --s 出发；只要某个组件私自修改了饱和度，整套同色系配色就会当场断链。这类问题往往在深色模式切换、品牌色更新或设计系统扩展时才会暴露出来，而后期修复的成本，通常远高于一开始就建立统一规范。
