改 color 或 background-color 本身不触发回流，但实际性能受元素类型、布局模式、色彩空间支持、图层策略及主线程负载等上下文影响，可能意外引发回流或高开销重绘。
改 color 或 background-color 本身不触发回流，但实际性能表现远不止“只重绘”这么简单——它是否卡顿，取决于你怎么写、在哪用、跟什么共存。
color 和 background-color 修改时为何有时会意外触发回流
表面上只是换色，但浏览器可能被迫重新计算布局：
-
inline元素加了background-image: linear-gradient(...)后撑开高度或换行，就不是纯重绘了 -
table里某个td改background-color，若它同时设了min-width，旧版 Chrome 可能误判尺寸可变，局部回流 - 用
color(display-p3)或color-mix()时，设备不支持对应色彩空间，降级过程伴随图层重建，合成开销上升 -
rgba(0,0,0,0)在部分低版本 Android WebView 中被识别为“不透明”，导致图层策略异常，比直接写transparent更容易出问题
rgba() vs rgb() + opacity：视觉一样，性能逻辑完全不同
解析耗时几乎一致，但底层行为差异明显：
-
rgba(255, 0, 0, 0.5)在 Safari 15.4 之前整条声明被跳过，实际生效的是上层叠的不透明色 - 某些 Android WebView 中，
rgba()会强制创建独立图层；而rgb()配合父级opacity可能复用已有图层，减少 GPU 合成压力 - 想让背景半透文字清晰？优先用
background-color: rgba(...)，别用opacity: 0.5—— 后者会让子元素一起变淡，还新建层叠上下文
大量 color 动画卡顿的真实原因不是“颜色太重”，而是调度时机
单个 color 动画开销极小，但并发量大或主线程忙时，就会暴露问题：
-
will-change: transform对color完全无效，它只对可合成属性（transform、opacity）起作用 - 200 个按钮同时 hover 变色，GPU 填充率（fill rate）可能打满，表现为卡顿而非掉帧
-
transform: translateZ(0)强制硬件加速，对颜色变化零帮助 - 最常被忽略的点：重绘本身不可怕，可怕的是 JS 正在跑长任务时，浏览器无法把重绘调度到合成线程——这时候哪怕只改一个
color，用户也会感知卡顿
真正影响性能的，从来不是颜色值本身，而是它所处的上下文：元素类型、父容器布局模式、色彩空间支持度、图层策略、以及当前主线程是否空闲。写 color: var(--primary) 很干净，但如果这个变量被 500 个组件高频读取并响应式更新，那瓶颈早就不在渲染管线里了。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
