纯色静态样式首选#RRGGBB（如#3a86ff），因其体积小、解析快、兼容性好；动态颜色或需透明度时用rgb()/hsl()更合适。
什么时候该用 #RRGGBB 而不是 rgb()？
纯色背景、边框、文字等静态样式，#RRGGBB（如 #3a86ff）仍是首选。它体积最小（7 字符）、解析最快、兼容性无死角——连 IE6 都认。但别硬套：如果颜色要动态计算（比如用 CSS 变量控制透明度），rgb() 或 hsl() 更直接，因为 rgba() 支持 alpha 通道，而 #RRGGBBAA 是较新语法（IE 完全不支持，Safari 12+ 才稳定）。
常见错误是把 #RGB（缩写）当成万能省略方案——它只适用于每个通道值形如 00、33、ff 这类重复数字，写成 #3af 看似省事，但和 #33aaff 并不等价（#3af 实际展开为 #33aaff，而 #3a86ff 无法缩写）。
rgb() 和 hsl() 哪个更适合团队协作？
hsl() 在语义表达上明显胜出：调整一个按钮的“更亮一点”，改 hsl(210, 100%, 60%) 的第三个参数比算 rgb(58, 134, 255) → rgb(80, 160, 255) 直观得多；做主题色变体（比如悬停态加深饱和度）也只需调第二个参数。但要注意：CSS 中的 hsl() 不支持 alpha 通道的简写形式（hsla() 存在，但部分旧版安卓 WebView 对 hsla(0,0%,0%,0.5) 解析异常），若需透明，rgb(0,0,0,0.5) 反而更稳。
使用场景差异：
立即学习“前端免费学习笔记（深入）”；
- 设计师给的是 Pantone 编号或“偏冷的蓝”，
hsl()更易逼近直觉； - 从 JS 动态生成颜色（比如数据可视化热力图），
rgb()更方便与数值运算对接； - 用 PostCSS 或 Sass 处理颜色函数时，
hsl()的 lighten()/darken() 比 rgb() 的 mix() 更可预测。
性能差异真的存在吗？浏览器怎么解析这些格式？
现代浏览器对三者解析开销几乎可以忽略——真正影响性能的是颜色变更触发的重绘（repaint），而非格式本身。但有两个隐蔽点：
- 频繁通过 JS 修改
element.style.color = '#3a86ff'和element.style.color = 'rgb(58, 134, 255)'，后者在 V8 引擎中字符串拼接成本略高（需转数字再转字符串）； - CSS-in-JS 库（如 Emotion）若将
hsl()写死在模板字符串里，可能因语法树解析稍慢于十六进制（实测差距在纳秒级，仅大量内联样式时可测）。
真正拖慢的从来不是颜色格式，而是滥用 !important 导致的层叠计算，或在 will-change: color 上乱加动画。
别忽略 CSS 自定义属性与颜色格式的配合陷阱
用 --primary: #3a86ff 定义变量很常见，但一旦想在此基础上调透明度，就得切到 rgb()：color: rgb(from var(--primary) r g b / 0.8)（需要 from 语法支持）。这个语法目前仅 Chromium 111+ 和 Safari 16.4+ 支持，Firefox 尚未实现。所以更稳妥的做法是初始就定义为 --primary-rgb: 58, 134, 255，再用 rgb(var(--primary-rgb) / 0.8)。
另一个坑：Sass 中 lighten(hsl(210, 100%, 50%), 10%) 和原生 CSS hsl(210, 100%, 60%) 数值结果并不严格一致——Sass 的 lighten() 基于 HSL 模型但做了视觉补偿，而原生 CSS 是线性插值。跨工具协作时，这点色差容易被忽略。
