如何修复CSS的hsl颜色在暗黑模式下不协调

直接调高文字色L%至82%–85%、压低背景L%至12%–20%最可靠，因HSL的L%是线性绝对值而非感知亮度，暗背景下人眼对60%–75%L值极度不敏感，需重算明度基准并实测验证。

直接调高文字色的 l% 到 82%–85%，同时压低背景色的 l% 至 12%–20%，比改色相或硬调饱和度更稳——HSL 的 l% 是绝对值，不是感知亮度，同一组 h/s 在暗背景下必须重算明度基准。

为什么 hsl() 在暗色模式下“看起来不对”

不是颜色写错了，是 HSL 的 l% 参照系没切换：它始终以全白（100%）到全黑（0%）为线性标尺，但人眼在暗背景下对中高 l%（比如 60%–75%）极度不敏感。例如 hsl(210, 100%, 70%) 在 #1e1e1e 上实测对比度可能仅 ≈3.4:1，远低于 WCAG AA 要求（4.5:1）。这不是浏览器 bug，是视觉恒常性导致的生理限制。

1. 别信肉眼判断，用 Chrome DevTools 的「Accessibility」面板实时测元素对比度
2. currentColor 不继承 background-color，它只读取元素自身的 color 值，和背景无关
3. 小字号（≤14px）时，l% 低于 80% 就容易发虚；OLED 屏幕上 l: 100%（纯白）反而边缘辉光、泛青

怎么用 hsl() 手动推导协调的深色变体

保持色相 h 不变，只调 l% 和 s%：背景降 l%，文字提 l%，再微调 s% 防止发闷。不要用 calc() 动态算，所有值必须手调并实测。

1. 浅色主色：hsl(210, 100%, 60%) → 深色背景：hsl(210, 100%, 12%)（同色相，l% 压至 12%）
2. 对应文字色：hsl(210, 100%, 92%)（不是 100%，冷调白更耐看）
3. 图标/强调色：hsl(12, 55%, 38%)（l% ≤40%，s% ≤60%，避免跳色）
4. 禁用 hsl(0, 0%, 0%)（纯黑）和 hsl(0, 0%, 100%)（纯白）作主色——它们在暗模式里缺乏层次，易视觉疲劳

为什么只写 @media (prefers-color-scheme: dark) 还是失效

CSS 变量本身不响应媒体查询。:root { --bg: #fff } 不会在暗色环境下自动变值，必须把整套变量定义放进媒体查询里，并加 fallback。

1. 基础定义必须存在：:root { --text-primary: hsl(210, 100%, 20%); }
2. 覆盖定义必须完整：@media (prefers-color-scheme: dark) { :root { --text-primary: hsl(210, 100%, 83%); } }
3. 所有使用处加 fallback：color: var(--text-primary, #e0e0e0);，否则变量未定义时样式崩
4. 必须声明 color-scheme: light dark，否则 <input>、滚动条等原生控件仍按亮色渲染

如何避免 hsl() + alpha 在暗色下更脏

hsla() 不是柔化手段，而是混合操作。高 l% + 高 s% 的基色叠透明度，会在深灰背景上引发光学振动，尤其小字号时边缘模糊。

1. 真正有效的降刺眼方式是先压 l%（如从 50% → 25%），再微调 s%（如从 100% → 40%），最后才考虑加 a
2. 如果必须用透明，选 l% 已压低的基色，例如 hsla(200, 40%, 25%, 0.9)，而非 hsla(200, 100%, 70%, 0.3)
3. 半透明色叠加深色背景后的真实灰度，无法靠调 hsl() 简单修复，得用工具反推混合后色值再校准

最易被忽略的是：l% 调整幅度 ≤10% 就可能让文字“抢焦点”或“发虚”，而大幅调 s% 反而影响小；OLED 屏幕的子像素混色、系统字体抗锯齿策略、甚至用户瞳孔状态，都会让同一组 hsl() 在不同设备上表现差异巨大——必须真机在暗室里关顶灯实测，不能只信工具数值或眼睛。