css颜色写法对渲染性能影响可忽略，因浏览器在样式计算阶段即统一转为rgba；真正影响性能的是动态计算、强制同步布局及图层重组等间接因素。
CSS 颜色表示方式本身对页面渲染性能的影响微乎其微，几乎可以忽略——浏览器解析 rgb(255, 0, 0)、#ff0000 或 red 的开销差异在纳秒级，不会成为性能瓶颈。
为什么颜色写法基本不影响重绘/重排
颜色值属于 CSS 中的「简单属性值」，在样式计算（style calculation）阶段就被转为统一的内部表示（通常是 RGBA 四元组），后续布局、绘制、合成阶段完全不关心你当初写的是十六进制还是 HSL。实测 Chrome DevTools 的「Rendering」面板中切换不同颜色写法，Layout、Paint、Composite 时间无任何可观测变化。
真正可能产生间接影响的场景
以下情况不是颜色本身拖慢性能，而是写法诱发了更深层的问题：
-
hsl()或hsla()在大量动态计算时（比如配合 CSS 自定义属性 +calc()实时生成渐变色）可能增加样式计算复杂度，尤其在低端设备上反复触发style recalc - 滥用
transparent替代rgba(0,0,0,0)通常没问题，但若与background-blend-mode或mix-blend-mode混用，可能意外触发额外的合成层（compositing layer），增加 GPU 内存占用 - 在关键动画元素（如
transform或opacity动画）中，把颜色写成rgb()并配合 JS 动态拼接字符串（如element.style.backgroundColor = 'rgb(' + r + ',' + g + ',' + b + ')'），会强制触发「强制同步布局（forced synchronous layout）」——因为浏览器需先读取当前 computed style 才能做字符串拼接，比直接设element.style.backgroundColor = '#f00'更容易卡顿
推荐优先使用的颜色写法（兼顾可维护性与潜在稳定性）
性能之外，更值得关注的是可读性、可维护性，以及某些写法在特定上下文中的隐含行为：
立即学习“前端免费学习笔记（深入）”；
- 静态颜色：优先用
#rrggbb或#rgb—— 解析最快，无函数调用开销，兼容性最好（包括 IE9+） - 需要透明度：用
rgba(r,g,b,a)而非hsla()，前者是硬件加速路径更成熟；避免用opacity控制单个元素透明度来“模拟”半透颜色，它会影响整个子树渲染层级 - CSS 变量场景：定义基础色用
--primary: #3b82f6，需要透明变体时显式定义--primary-50: rgba(59, 130, 246, 0.5)，而不是在使用处写hsla(var(--h), var(--s), var(--l), 0.5)增加运行时计算 - 禁用
currentColor在高频动画中作为颜色源——它依赖于父级color计算链，一旦父级 color 动态变化，可能引发意料外的样式重算
真正要盯紧的从来不是 #fff 还是 white，而是颜色变更是否触发了 layout、是否导致图层重组、是否在主线程里做了大量字符串拼接。把注意力放在这些地方，比纠结颜色写法更能守住性能底线。
