根本原因是浏览器将渐变当作位图渲染，每次重绘需重新生成图像，导致GPU带宽饱和掉帧；应减少层数、用十六进制色值、禁用透明度、必要时降级Canvas并设image-rendering: pixelated。
为什么 linear-gradient 在低端机上卡顿
根本原因不是写法错，而是浏览器把渐变当“位图”渲染——每次重绘都要生成一张新图，和加载 background-image: url(gradient.png) 没本质区别。中低端 Android（尤其 Chrome 80–100）、iOS 14–15 的 WebKit 对这类操作没有降级路径，GPU 带宽一满就掉帧。
常见现象包括：页面滚动时渐变背景闪烁、文字渐变动画卡在 20–30 FPS、首屏加载后 CPU 占用持续高于 60%。
减少渐变层数：别用多层叠加实现“丰富感”
开发者常堆叠多个 linear-gradient 或混用 radial-gradient 来模拟光效，但每加一层，浏览器就要多算一次采样+合成。低端设备上，3 层以上渐变基本等于放弃帧率。
- 把
background: linear-gradient(...), linear-gradient(...), radial-gradient(...)改成单层渐变 +box-shadow模拟高光（注意：仅限非关键区域，box-shadow本身也耗性能） - 避免用
repeating-linear-gradient做纹理，改用小尺寸 base64 图片或 SVG data URI - 如果必须多色过渡，用 3–4 个色标就够了：
linear-gradient(135deg, #ff9a9e, #fad0c4, #a1c4fd)，别写 6–8 个停靠点
简化颜色值：十六进制比 rgb() 和 hsl() 更快
不是语法问题，是解析开销。WebKit 和 Blink 在低端设备上解析 rgb(255, 154, 158) 或 hsl(357, 100%, 80%) 需要额外计算步骤，而 #ff9a9e 是直接查表映射。
实测在 Android 9 + Chrome 95 上，10 个元素同时用 hsl() 渐变，比等效 # 写法平均多占用 12ms 主线程时间。
- 所有渐变色一律用 6 位十六进制，禁用带透明度的
rgba()或hsla() - 避免在渐变中混用单位，比如
linear-gradient(to right, #ff9a9e 0%, rgba(250, 208, 196, 0.8) 100%)—— 透明度会强制启用 alpha 合成通道，进一步拖慢 - 如需淡入淡出效果，用
opacity控制整个元素，而不是在渐变里做 alpha 过渡
真·低端设备兜底：用 Canvas 替代 CSS 渐变
当目标设备明确是 Android Go 版、旧款红米/荣耀入门机，或 TV 盒子（WebOS、Tizen），CSS 渐变已不可信。此时应主动降级为 Canvas 绘制静态渐变图。
关键不是“能不能画”，而是“要不要实时重绘”：
- 只在初始化时 draw 一次，不监听 resize 或 orientationchange —— 动态适配交给 CSS
background-size: 200% 200%+background-position - Canvas 尺寸按
window.devicePixelRatio缩放，但绘制逻辑保持整数坐标，避免 subpixel 模糊触发额外抗锯齿 - 渐变方向固定用
createLinearGradient(0, 0, width, height)，别用角度计算，省去三角函数调用
最易被忽略的一点：Canvas 生成的渐变图必须设为 image-rendering: pixelated，否则在 DPR > 1 设备上会被浏览器自动插值模糊，反而增加渲染负担。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
