linear-gradient() 本身性能优异，但误用会导致重绘、样式计算负担加重及兼容性问题；应优先使用角度写法、添加 background-color fallback、避免与 backdrop-filter 或 img-fluid 混用，并注意深色模式下的渐变与颜色同步更新。
background-image: linear-gradient() 本身几乎不拖慢渲染
渐变背景是纯 CSS 合成，不触发重排（reflow），也不加载外部资源，浏览器直接在合成层（compositor layer）里画出来。只要没配错写法，它比一张 background-image: url(gradient.png) 还轻量。
但真实性能损耗往往来自误用场景：
- 给大量元素（比如每行
.card）都加独立渐变，会显著增加样式计算和绘制层的负担 - 在
@media里反复声明不同方向/颜色的渐变，尤其是嵌套多层断点时，CSS 规则体积膨胀，影响首屏解析速度 - 搭配
backdrop-filter: blur()一起用——这才是真·性能杀手，模糊滤镜强制启用 GPU 渲染，低端安卓机或旧 iPad 上容易掉帧
移动端 Safari 的渐变重绘陷阱
iOS 15–16.3 的 WebKit 存在一个已知问题：当渐变方向用 to right 或 to bottom 时，滚动过程中会频繁触发重绘，造成卡顿；换成角度写法（如 90deg、135deg）就能绕过。
实操建议：
- 始终优先用角度（
linear-gradient(135deg, #0d6efd, #6f42c1)），别用to关键字 - 避免在
:hover或@keyframes中动态切换渐变方向——WebKit 不支持渐变插值，只会硬切，视觉突兀且触发重绘 - 如果必须做悬停动效，改用
opacity或transform过渡，渐变保持静态
与 img-fluid、高 DPR 图片混用时的隐性开销
渐变本身没分辨率问题，但很多人把它和 img-fluid 放在同一容器里，再叠加 background-size: cover —— 这会导致浏览器持续计算缩放比例和裁剪区域，尤其在窗口 resize 频繁时（比如横竖屏切换）。
更隐蔽的问题是：如果容器内有 SVG 或高倍图，而渐变又用了 background-attachment: fixed，部分 Android WebView 会错误地把渐变当作位图处理，放大后出现色带或锯齿。
稳妥做法：
- 渐变容器不要设
background-attachment，除非明确需要视差效果 - 避免把渐变和
img-fluid套在同一div里；分开层级，用伪元素::before承载渐变，主内容层只管图片和文字 - 检查 DevTools 的 Rendering 面板，开启 “Paint flashing”，滚动时看渐变区域是否高频闪烁——闪得越勤，重绘压力越大
真正该警惕的不是渐变，而是 fallback 色缺失
漏写 background-color fallback 看似只是设计降级，但在低配设备上可能引发连锁反应：某些旧版 Chromium 内核（如微信 X5 7.0.23）遇到无 fallback 的 linear-gradient，会跳过整个 background 解析，导致容器透明，进而触发父层重绘+子元素重叠判定，最终帧率骤降。
所以这行不能省：
div.hero {
background-color: #f8f9fa; /* 必须有 */
background-image: linear-gradient(135deg, #0d6efd, #6f42c1);
}复杂点在于：同一组渐变在深色模式下 fallback 色要换，否则对比度崩；而 @media (prefers-color-scheme: dark) 里只改 background-color 不够，得同步更新渐变色 stops，否则浅色渐变落在深灰背景上，文字可读性直接归零。
