background-color transition卡顿主因是RGB非线性插值引发重排重绘及合成层切换，且will-change反而加重负担；应优先用linear-gradient位移模拟变色或color-mix()指定色彩空间。
为什么用 transition 动画 background-color 会卡顿
直接对 background-color 做 transition（比如从 #ff0000 到 #00ff00），浏览器底层需要实时插值计算每帧的 RGB 值，尤其在低端设备或高刷新率屏幕下，容易触发重排+重绘+合成层切换，导致掉帧。更关键的是：十六进制或 hsl() 颜色在插值时不是线性感知的，浏览器强行做数值插值，视觉上会出现“突变感”，反而被误判为卡顿。
用 rgb() 替代不是关键，关键是用 color-mix() 或分通道控制
单纯写成 rgb(255, 0, 0) → rgb(0, 255, 0) 并不会提升性能——CSS 仍按相同机制插值。真正有效的做法是：
- 确保起始/结束色都用
rgb(r, g, b)或rgba(r, g, b, a)显式声明（避免浏览器隐式转换开销） - 若需精细控制节奏，改用
@keyframes+rgb()分通道动画（例如只动g通道），但仅适用于简单场景 - 现代方案优先用
color-mix(in srgb, color1, color2)配合transition，它明确指定色彩空间，插值更稳定（Chrome 111+、Safari 16.4+ 支持）
will-change: background-color 反而可能加重卡顿
给元素加 will-change: background-color 会让浏览器提前为其创建独立合成层，但颜色过渡本身不涉及位置/缩放等需要合成的属性，这反而增加内存占用和图层管理负担，实测在中低端 Android 设备上帧率下降更明显。
更稳妥的做法是：
远程控制 Android 设备，支持截图、自动化操作手机 App 等功能。本应用使用 uiautomator2 作为底层框架，通过 ADB 连接设备，用户无需 Root（1）查看手机屏幕；（2）自动化操作手机 App；（3）远程安装/卸载应用……
立即学习“前端免费学习笔记（深入）”；
- 确认该元素已处于自己的合成层（例如已有
transform: translateZ(0)或opacity动画） - 避免同时对多个颜色属性（
color、background-color、border-color）做transition - 动画时长控制在
200ms–300ms，过长会放大插值误差，过短则易触发渲染瓶颈
真·平滑替代方案：用 linear-gradient 模拟纯色过渡
这不是绕路，而是利用 GPU 加速的渐变绘制机制。原理是把单色背景转为 1px 高的垂直渐变，再通过 background-size 和 background-position 控制“可见区域”，让颜色变化由位移驱动——全程走合成器管线，不触发重绘。
button {
background: linear-gradient(to bottom, #ff0000, #ff0000);
background-size: 100% 200%;
background-position: 0 0;
transition: background-position 0.25s ease;
}
button:hover {
background-position: 0 100%;
}
注意：该技巧依赖渐变起点与终点色一致（即视觉上是纯色），靠位移“扫过”不同色带来模拟变色。兼容性好（IE10+），且在低功耗设备上帧率稳定。
实际项目里，卡顿往往不是出在颜色格式，而是过渡属性没收敛、动画未隔离到合成层、或同时触发了 layout —— 先用 Chrome DevTools 的 Rendering 面板勾选 “Paint flashing” 和 “FPS meter”，看哪一帧在重绘，再决定改 rgb() 还是换机制。
