直接拆分H、S、L为独立CSS变量是最可控、可维护的方式；硬塞整个hsl()字符串会锁死所有参数，丧失动态调色能力，无法单独调整任一维度。
直接把 HSL 的三个分量拆成独立 CSS 变量，是最可控、最可维护的方式；硬塞整个 hsl() 字符串进一个变量，等于放弃动态调色能力。
为什么不能只用一个变量存整个 hsl(210, 70%, 60%)
因为那样就锁死了所有参数——改色相要重写整条字符串，改亮度得先解析再拼接，JS 操作也得字符串匹配。真正需要的是“按需替换某一项”。
常见错误现象：--primary-color: hsl(210, 70%, 60%)，然后在样式里写 color: var(--primary-color)，看似省事，实则丧失所有灵活性。
正确做法是分开定义：
:root {
--primary-h: 210;
--primary-s: 70%;
--primary-l: 60%;
}
button {
background-color: hsl(var(--primary-h), var(--primary-s), var(--primary-l));
}这样换主题时只需改 --primary-h，禁用态只需改 --primary-s，深色模式只需改 --primary-l，互不干扰。
hsl() 里用 var() 和 calc() 的边界在哪
var() 可以直接嵌入 hsl() 的任意位置，但 calc() 有硬性限制：
– 色相（h）必须是无单位整数，calc(var(--h) + 30) ✅，calc(var(--h) + 30deg) ❌
– 饱和度和亮度（s/l）必须带 % 单位，calc(var(--s) * 0.8) ✅，calc(var(--s) * 0.8%) ❌（单位重复）
– calc() 不能跨类型混算，比如 calc(var(--h) + var(--s)) 会失败，因 --s 是带 % 的字符串，无法与数字相加
典型误用：hsl(calc(var(--h) + 30), calc(var(--s) - 20%), var(--l)) → 第二个参数缺单位，整条声明被浏览器忽略
立即学习“前端免费学习笔记（深入）”；
深色模式下 hsl() 调亮度的实际表现比想象中复杂
HSL 的 lightness 不是线性明暗控制，尤其在 0%–30% 区间，人眼对微小变化极其敏感，且不同色相的“视觉黑度”差异极大。
容易踩的坑：
– 直接把浅色模式的 l: 60% 改成 l: 20%，结果不是深蓝，而是泛青灰或棕灰（尤其在 OLED 屏）
– 高饱和色配低亮度（如 hsl(180, 90%, 15%)）会显脏，像蒙了层油膜
更稳妥的做法：
– 深色模式优先设 --primary-s: 0%，先去色，再微调 --primary-h 做冷暖校正（比如 --primary-h: 210 比 0 更中性）
– 用 DevTools 颜色拾取器切到 HSL 模式看实时三值，别信颜色预览小方块
Shadow DOM 或局部作用域里变量突然失效
变量没生效，八成是作用域断了。
:root 定义的变量不会自动穿透 Shadow DOM；组件内部如果写了 :host { --primary-h: 180; }，会覆盖全局值，但子元素拿不到，除非显式继承或透传。
使用场景：
– Web Components 中，需在 :host 或 ::slotted 里重新声明变量，或用 inherit 强制继承
– CSS-in-JS 库（如 Emotion）可能默认隔离作用域，得查文档确认是否支持 :root 变量注入
– 多主题切换时，避免在 .theme-dark 类里重复定义全部变量，只覆盖变动项（如只改 --primary-l），减少冗余和冲突
