博客主页瑕疵的CSDN主页 Gitee主页瑕疵的gitee主页⏩ 文章专栏《热点资讯》CSS will-change用得溜页面滚动不卡顿目录上周在移动端项目里滚动列表卡成PPT。用户一滑页面就卡住像在拖动一坨泥。测试时Chrome DevTools的FPS直接掉到10看着就心梗。问题来了为啥好好的滚动会卡浏览器渲染时每次滚动都触发重排重绘。尤其当元素有transform或opacity浏览器得重新计算布局——这玩意儿在低端手机上就是慢性自杀。根源浏览器渲染流水线太“懒”。默认情况下浏览器不会提前优化滚动元素。它会等到滚动发生时才处理结果就是卡顿。will-change就是给浏览器打个招呼“这个元素要动提前准备好” 它提前创建合成层让滚动变成GPU加速的流畅动画。正确用法先看错误写法滚动必卡/* 错误没用will-change滚动时浏览器临时计算布局 */.list-item{transform:translateX(10px);/* 滚动时触发重排 */transition:transform0.3s;}再看正确写法丝滑如丝绸/* 正确用will-change提前声明 */.list-item{will-change:transform;/* 关键告诉浏览器要动 */transform:translateX(10px);/* 真正的动画 */transition:transform0.3s;}避坑总结血泪教训别乱加只对滚动时会动的元素用。比如给div classscroll-item加别给body加——我试过内存直接爆手机变砖。用完要收动画结束后记得移除。加will-change: auto避免无用图层占用内存。.list-item.active{will-change:transform;}.list-item.inactive{will-change:auto;/* 动画结束回收资源 */}测试看LayersChrome DevTools → More Tools → Layers。确认图层已创建别白忙活。移动端优先PC端可能不明显但手机用户绝对要命。实际项目里我给滚动列表的每个item加了will-change: transform滚动流畅度直接从20FPS飙到60FPS。之前同事傻乎乎地用opacity做动画结果滚动卡成PPT——现在他懂了will-change不是万能药是精准的手术刀。最后说句大实话别等用户投诉卡顿了才改。写代码前先问自己“这个元素滚动时真会动吗”动就加will-change不动就别折腾。用对地方滚动才不卡。下次再卡别骂浏览器先看CSS。