真正卡顿的根源是background-position动画、background-size变化或:hover/:active中反复切换渐变方向，导致每帧重绘，尤其在ios safari和旧版android webview上明显。
background-image: linear-gradient() 本身不卡，卡在哪儿
渐变背景本身是纯 CSS 渲染，不触发重排（reflow），但一旦和动画、响应式切换或滚动联动，就容易掉进移动端的合成陷阱。真正卡顿的根源通常是：background-position 动画、background-size 变化、或在 :hover/:active 中反复切换渐变方向——这些操作会强制浏览器每帧重绘（repaint），尤其在 iOS Safari 和旧版 Android WebView 上表现明显。
渐变按钮 + hover 动画一动就卡的解法
很多人给 .btn 加 background-image: linear-gradient() 后，再写 transition: background 0.3s，结果点击瞬间跳变或延迟响应。这不是渐变的问题，而是浏览器根本不支持 background-image 的插值过渡。
- 别写
transition: background—— Chrome/Firefox 不支持渐变插值，只会硬切 - 改用
transition: opacity 0.2s配合两个不同渐变的类切换（如.btn-gradient和.btn-gradient-hover） - 如果真要“动”渐变，只允许用
transform: translate()模拟位移（比如配background-position的平移效果），且必须加will-change: transform在交互触发前一刻 -
:active状态务必显式定义，iOS Safari 对伪类渲染极不稳定，漏写就等于没反馈
响应式渐变背景在小屏下闪退或错位
用媒体查询控制渐变是否生效时，常见错误是直接在 @media (max-width: 768px) 里删掉 background-image，结果小屏加载时先渲染渐变、再回退到纯色，出现视觉闪烁。更糟的是，某些安卓 WebView 会在媒体查询切换时丢掉 backdrop 层级，导致文字边缘发虚。
- 渐变和非渐变状态必须用同一套背景逻辑：小屏下不是“去掉渐变”，而是换成单色
background-color: #0d6efd+background-image: none - 避免在媒体查询里用
!important，改用更高权重选择器，例如.hero-section:not(.no-gradient)控制全局，再用.hero-section.no-gradient-sm覆盖小屏 - 如果背景挂载在
.container-fluid上，确保它没被父级overflow: hidden截断——渐变图层超出容器时会被裁剪，看起来像突然消失
最隐蔽的卡点：字体加载 + 渐变背景叠加
渐变背景上放文字时，若字体用的是 @import 引入的 Google Fonts 或自定义 webfont，首次渲染会触发 FOIT（Flash of Invisible Text），而浏览器在字体回填瞬间可能重绘整个背景区域——尤其当渐变角度随视口变化（如用 background-image: linear-gradient(135deg, ...)）时，这种重绘会被放大成肉眼可见的抖动。
- 把字体声明移到
最前，并加font-display: swap - 渐变背景容器加
contain: layout paint style，限制重绘范围（注意 Safari 15.4+ 才稳定支持） - 别依赖
vh单位做渐变起点/终点位置——缩放页面或地址栏弹出时，100vh值突变会触发背景重算；改用固定像素或rem基准
div 错误地分配到了 CPU 渲染管线，而不是 GPU 图层。这时候光改代码没用，得靠 Safari Web Inspector 的 Rendering 面板看“Compositing Reasons”。
