HSL比RGB更适合移动端开发，因其色相、饱和度、亮度解耦，主题切换、暗色适配、状态变体只需调整单一参数，避免RGB三通道联动导致的偏色、发灰；暗色模式l值推荐10%–30%，色相与饱和度锁定不变，确保色彩干净可控。
移动端开发中优先用 hsl() 不是因为它“更先进”，而是它能直接解决高频痛点：主题切换、暗色适配、状态变体批量生成——这些事用 rgb() 做，要么靠工具算，要么手动试错，还容易偏色。
暗色模式下改 l 值比调 rgb() 通道稳得多
移动端暗色模式要求文字、背景、边框同步变暗，但不能发灰、不能偏紫。用 hsl(205, 90%, 50%) → hsl(205, 90%, 15%) 直接压低 l，色相和饱和度锁死，整套蓝调保持干净；而 rgb(42, 110, 255) 改成 rgb(21, 55, 127) 或 rgb(12, 80, 225)，R/G/B 任意通道一动，色相就漂移，饱和度也塌缩，最后颜色发青或发紫。
-
l推荐区间：暗色模式用10%–30%，卡在5%趋近纯黑，色相信息丢失 - 别用
rgb()手动乘系数或减固定值——浏览器不认“视觉等比”，只认通道数值 - Chrome DevTools 颜色拾取器点一下就能把设计稿里的
#2a6eff转成hsl(210, 90%, 50%)，比查表快
按钮/组件状态变体用 hsl() 一行代码搞定
移动端按钮常需默认态、悬停态、禁用态三套颜色，且要视觉协调。用 hsl() 只调一个参数：hsl(205, 90%, 50%)（默认）→ hsl(205, 90%, 65%)（悬停，提亮）→ hsl(205, 30%, 75%)（禁用，降饱和+提亮）。RGB 没这种语义化控制能力，得开取色器一个个配，稍有偏差就显得“不是一套”。
- 悬停时只改
l：从50%→65%，不碰h和s，避免色相漂移 - 禁用态重点是降
s（30%左右），不是单纯变灰——s太低（<20%）时，再怎么调h人眼也看不出区别 - 所有状态共用同一个
--hue变量，换主题只需改一处：:root { --hue: 205; }
HSL 动画过渡比 RGB 更平滑，尤其跨色相时
移动端常用色相动画（比如加载指示器从蓝转绿），hsl(220, 100%, 50%) → hsl(180, 100%, 50%) 浏览器会沿色环最短弧线过渡，全程高彩度；而 rgb(0, 128, 255) → rgb(0, 255, 255) 是线性插值，中间必经 rgb(0, 191, 255) 这类带灰阶的青，出现“断层感”。
立即学习“前端免费学习笔记（深入）”；
- 浏览器自动处理
hsl(355deg, 90%, 60%)→hsl(5deg, 90%, 60%)为+10°，不是-350°，跨 0° 无缝 - 必须写单位：
deg缺失时，旧版 Safari 可能解析失败，别写成hsl(355, 90%, 60%) -
s和l要守安全区：s: 60%–90%，l: 30%–70%，否则动画变成“明暗闪烁”而非“流光”
真正卡住人的不是语法，是混用时的隐性成本：比如 SCSS 的 lighten(#2a6eff, 10%) 结果依赖 Sass 算法，和 CSS 原生 color-mix(in srgb, #2a6eff 70%, white) 行为不一致。移动端迭代快，能少一层转换就少一层风险。
