性能无差异——所有颜色格式在浏览器解析阶段即统一转为RGBA内部表示，耗时差不到1ns；真正影响性能的是跨格式混用、CSS变量配合calc()运算及旧版WebView兼容性问题。
性能上没有差异——#FF5733、rgb(255, 87, 51)、hsl(14, 80%, 57%)在浏览器解析阶段就被统一转为 RGBA 内部表示，耗时差不到 1ns。
为什么现代浏览器里颜色格式解析开销可忽略
Chrome/Firefox/Safari/Edge 在 CSS 解析阶段就完成格式归一化：所有合法颜色值（包括 hsl()、hex、rgb()）都会被立即转换成 4 个浮点数的 RGBA 元组（如 [1.0, 0.34, 0.2, 1.0]），后续布局、绘制、合成全部复用该结果。
-
hsl(210, 100%, 60%)不是运行时计算，而是解析时一次性算出对应 RGB 值再存入样式系统 - 实测百万次赋值，不同格式间无统计显著性差异
- 真正触发重排重绘的是 JS 频繁修改
style.color，不是你写了#F53还是rgb(255,87,51)
哪些组合会真实拖慢低端设备
问题不出在单个颜色值本身，而出在格式混用 + 动态机制引发的隐式开销：
-
hsl()在大量元素上（如 50 个卡片 hover）比等效#ff9a9e多占 8–12ms 主线程——因需做色域映射（sRGB 转换），低端 CPU 吃紧 -
rgba()会强制创建独立合成层，3 个以上叠加可能挤占 GPU 内存，导致动画掉帧 - 渐变中混用
#ff9a9e 0%和rgba(250, 208, 196, 0.8) 100%，会全程启用 alpha 通道，GPU 填充率翻倍 - 旧版 Android WebView（Chrome ≤90）可能直接忽略
hsla()，回退到继承色，造成视觉异常并触发重绘
什么时候格式选择真会影响表现
仅当涉及 CSS 变量与运行时计算时，格式才暴露能力边界：
立即学习“前端免费学习笔记（深入）”；
-
--main: #FF5733;+background: color-mix(in srgb, var(--main), white 70%);→ 安全高效 -
--main: hsl(14, 80%, 57%);+background: hsl(calc(var(--hue) + 20), 80%, 57%);→ 无效：CSS 不支持对hsl()参数做calc() -
--r: 255; --g: 87; --b: 51;+background: rgb(var(--r), var(--g), var(--b));→ 合法但冗余，且无法控制 alpha
真正要盯的不是字符串长度或写法“优雅”，而是目标环境是否支持你选的格式（比如 iOS 9.3 不认八位 HEX #FF573380）、变量是否塞了无法参与计算的结构、以及有没有在滚动区域里滥用 rgba() 背景。这些细节在高端机上无感，在低端机上就是掉帧开关。
