修改color、background-color等纯视觉属性通常只触发重绘而不引发回流，但若涉及inline元素背景撑开、table/flex中min-width误判、色彩空间降级、rgba图层强制创建或大量并发重绘等情况，可能间接导致回流或显著性能损耗。
修改 color、background-color 这类纯视觉属性，确实只触发重绘（Repaint），不引发回流（Reflow）——但前提是它真的“只改颜色”，且没意外牵连布局。
哪些颜色操作会悄悄触发回流
表面上只是换色，实际却迫使浏览器重新计算布局的情况并不少见：
-
background-image换成带渐变或url()的值时，如果该元素原本是 inline 元素（如<span>），且新背景导致内容撑开、换行或影响基线对齐，就可能间接触发回流 - 在
table或flex容器中修改子项的background-color，若该子项设置了min-width/flex-basis且内容边界模糊，某些旧版 Chrome 会误判为尺寸可变，触发局部回流 - 使用
color-mix()或color(display-p3 ...)时，若设备不支持对应色彩空间，浏览器降级渲染可能伴随图层重建，带来额外合成开销（虽非严格回流，但性能影响类似）
rgba() vs rgb() / hex：解析无差别，但透明度有陷阱
浏览器把 rgba(255, 0, 0, 0.5) 和 rgb(255 0 0 / 0.5) 都归一化为相同内部表示，解析耗时几乎一致。真正差异在兼容性与隐式合成：
- Safari 15.4 之前完全忽略
rgb(r g b / a)中的 alpha 通道，整条声明被跳过 → 实际生效的是上层层叠的不透明色，看似“没变”，实则漏了透明效果 -
rgba()在部分 Android WebView 中会强制创建独立图层（layer），而rgb()+opacity可能复用父层 —— 图层数量增加会抬高合成阶段成本 - 写
background-color: transparent而非background-color: rgba(0,0,0,0)更安全：前者明确语义，后者在某些低版本内核中会被错误识别为非透明色
动画中改颜色是否真“便宜”
单独用 color 或 background-color 做 CSS 动画，看似轻量，但要注意：
立即学习“前端免费学习笔记（深入）”；
- 在开启了
will-change: transform的容器里改color，不会提升性能；will-change对纯重绘属性无效 - 大量元素同时重绘（比如 200 个按钮 hover 变色），即使单次开销小，GPU 填充率（fill rate）也可能成为瓶颈，表现为卡顿而非掉帧
- 使用
transform: translateZ(0)强制硬件加速，对颜色变化毫无帮助；它只对transform、opacity等可合成属性起作用
最常被忽略的一点：重绘本身不可怕，可怕的是它发生在主线程繁忙时（比如 JS 正在执行长任务），而浏览器无法把重绘调度到合成线程。这时候哪怕只改一个 color，用户也会感知卡顿。
