will-change 并非万能，滥用会导致图层过多、内存飙升和掉帧。应仅对明确频繁动画的元素使用，避免嵌套设置，配合图层检测与及时销毁，并优先于 translateZ(0)。

为什么 will-change 加了反而更卡

不是所有滚动容器都适合加 will-change: transform。浏览器会提前把元素提升为独立图层，但图层过多会导致内存占用飙升、合成器压力增大，尤其在低端 Android 设备上，反而触发频繁的图层重绘和掉帧。

• 只对「明确会动且动得频繁」的元素设 will-change，比如列表页中正在做下拉刷新动画的 .refresh-header，而不是整个 .list-container
• 避免在父容器上设置后，子项又各自设置——图层嵌套叠加会放大开销
• 用 Chrome DevTools 的 Layers 面板确认是否真生成了新图层，别靠猜
• 设完必须配销毁逻辑：element.style.willChange = 'auto' 或用 CSS 动画结束时清除，否则图层常驻不释放

will-change 和 transform: translateZ(0) 到底选哪个

两者都能触发硬件加速，但机制不同：translateZ(0) 是“强制升层”，简单粗暴；will-change 是“声明式提示”，更轻量但依赖浏览器实现。实际项目中，优先用 will-change，除非遇到旧版 Safari（

• 兼容性兜底写法：

  element {
    transform: translateZ(0);
    will-change: transform;
  }

  浏览器会忽略不认识的属性，但保留有效加速
• will-change: scroll-position 对滚动容器无效——它只对 transform / opacity / contents 生效，别乱填
• 不要给 :hover 伪类直接设 will-change，悬停瞬间触发升层太晚，卡顿就在那一帧

移动端列表滑动卡顿，真正该先查什么

will-change 是止痛药，不是退烧药。90% 的列表卡顿根源在 JS 主线程阻塞或布局抖动，而不是渲染层没加速。

CSS工具箱(专业版)

全功能 CSS 工程手册，覆盖性能优化、无障碍、设计系统与跨浏览器兼容。

下载

• 打开 Chrome 的 Performance 面板录制滑动过程，重点看 Layout 和 Scripting 耗时是否超过 8ms/帧
• 检查是否在 scroll 事件里做了 getBoundingClientRect() 或改写了 style —— 这会强制同步回流
• 列表项内图片没设宽高？没用 loading="lazy"？这些比加 will-change 影响更大
• 用 IntersectionObserver 替代 scroll 监听做懒加载，避免主线程被拖住

Vue/React 列表中 will-change 的典型误用

框架组件封装容易掩盖底层渲染细节。比如 Vue 的 v-for 列表项如果用了 key 错误（如用 index），或者 React 中列表项内有未 memo 的回调函数，都会导致无谓重渲染——这时加 will-change 只是给垃圾回收器添堵。

立即学习“前端免费学习笔记（深入）”；

• 确保列表项是纯组件：Vue 用 defineComponent + shallowRef 控制更新粒度；React 用 React.memo + useCallback 稳定 props
• 不要在列表项组件根元素上统一加 will-change: transform，而是等用户真实开始拖拽时，再动态加到当前视口内的几项上
• 使用 CSS containment: paint 配合 will-change，能进一步限制重绘范围，但 iOS Safari 15.4 之前不支持

事情说清了就结束。真正卡的时候，先看 Performance 面板里哪一栏红得最狠，别急着加 will-change。