hsl(from) + calc() 是生成暗色调最稳的组合，需用 calc(l - 15) 调整亮度、calc(s * 0.7) 降饱和，并配合 clamp 或 max 防越界，禁用 currentColor 派生，oklch() 因兼容性差暂不推荐单色暗化。
hsl(from) + calc() 是生成暗色调最稳的组合
直接用 hsl() 写死明度值无法响应基础色变化，而 hsl(from var(--primary) h s l) 不做计算就等于原色——真正起作用的是 calc(l - 15) 这类对通道的数值运算。Safari 15.4+、Chrome 111+、Firefox 120+ 都已支持该语法，无需 polyfill。
常见错误是把 l 当作百分比参与计算：calc(l - 15%) 会失效，因为 HSL 的 l 是 0–100 的纯数字（不是单位值）；正确写法是 calc(l - 15)。
- 暗色调建议减 10–25 的亮度值，避免
l掉到 10 以下导致颜色发灰或不可见 - 同步降饱和度更自然：
calc(s * 0.7)比单纯调暗更符合视觉层次 - 禁用态文字推荐组合：
hsl(from var(--primary) h calc(s * 0.3) calc(l + 15))（提亮+降饱，防止在深背景上糊成一片）
别在 oklch() 里硬调 L 值做暗色
oklch() 的 L 是 0–1 小数，理论上更适合感知均匀的暗化，但当前兼容性仍是硬伤：Firefox 仍需 -moz-oklch() 且插值行为不一致，Safari 对低 L + 高 C 组合渲染不稳定，容易溢出可见色域。
实测中，oklch(from var(--primary) calc(L * 0.8) C H) 在 OLED 屏上可能突然变黑无细节，而同参数的 hsl(from ... calc(l - 12)) 更可控。真要用 oklch()，必须用 @supports (color: oklch(0 0 0)) 包裹并 fallback 到 HSL。
立即学习“前端免费学习笔记（深入）”；
- 不要对
oklch()的H（色相）做大幅偏移，数值跳变易跨视觉断层 -
C（色度）在L 时敏感度陡增，<code>calc(C * 0.5)比calc(C - 0.1)更稳 - 深色模式下，
oklch()的优势在于渐变过渡，单色暗化仍推荐 HSL
currentColor 不能当暗色生成器用
currentColor 是继承值，不是计算值——它永远等于父元素已计算出的 color，无法被 calc() 或 from 解构。你写 background-color: hsl(from currentColor h s calc(l - 10))，浏览器直接忽略整条声明，且不报错。
它只适合“复用颜色语义”，比如图标 fill: currentColor 自动匹配文字色，但绝不适合派生新色。想让按钮背景比文字色暗一点？必须先把文字色存为 CSS 变量，再基于变量运算。
- 错误写法：
color: #3b82f6; border-color: hsl(from currentColor h s calc(l - 15)) - 正确路径：
:root { --text-color: #3b82f6; } p { color: var(--text-color); } p::before { border-color: hsl(from var(--text-color) h s calc(l - 15)); } - SVG 内
currentColor依然有效，但仅限于填充/描边等接受颜色的属性，不能进from
边界值必须 clamp，否则深色模式翻车
自动调暗最大的坑不是算错，而是没防越界：calc(l - 30) 在基础色本就是 l: 20 时会产出负值，部分安卓 WebView 渲染为不可预测的黑或透明；calc(s * 1.5) 在高饱和色上可能爆色，尤其在 OLED 屏上泛白。
目前没有原生 clamp() 支持相对颜色通道，只能靠保守设计兜底。例如用 max(15%, calc(l - 20)) 保底亮度，或提前在变量层限制基础色范围（如主色 l 设为 40–70）。
- 深色背景上的文字，
l低于 25% 易读性骤降，WCAG AA 级要求对比度 ≥ 4.5:1 - 用
hsl(from var(--primary) h calc(max(20, l - 15)) calc(max(10%, s * 0.6)))比裸写calc()更安全 - 所有暗色调规则，建议加
@media (prefers-color-scheme: dark)双重保险，避免亮色主题下误触发
