will-change 对纯 css 列表滚动动画通常无效且有害；仅当容器固定尺寸、动画纯用 transform、项数超 50 且帧率低于 55fps 时，可谨慎加于内容容器。
will-change 对列表滚动动画真的有效吗
对纯 CSS 动画驱动的列表滚动（如 @keyframes + transform: translateY()），will-change 在多数现代浏览器中**不提升性能，反而可能引发内存泄漏或布局抖动**。它不是“开启硬件加速”的开关，而是向浏览器发出一个“我即将频繁变更这个属性”的提示——但前提是该属性确实被引擎识别为可合成（compositable）。transform 和 opacity 是安全的，而 top、left 或未加 transform 的 height 则不会触发合成层。
哪些场景下该加 will-change: transform
仅在满足以下全部条件时考虑添加：
- 滚动容器是固定尺寸、
overflow: hidden的块级元素 - 动画完全依赖
transform: translateY()（不能混用margin-top或top） - 列表项数量较多（> 50）、且动画帧率持续低于 55fps（可用 Chrome DevTools 的 Rendering 面板验证）
- 你已排除其他瓶颈：比如
box-shadow、filter、未裁剪的渐变背景等强制重绘因素
此时可加：will-change: transform 到滚动内容容器（如 .scroll-content），而非父容器。加在父容器上会导致整个区域被提升为合成层，浪费内存。
更有效的替代方案：避免 will-change 的硬优化
比起盲目加 will-change，这些改动见效更快、风险更低：
- 用
transform: translateY(-50%)替代top: -50%—— 后者永远无法合成 - 确保
.scroll-content没有border、outline或box-shadow；若有，用backdrop-filter: blur(0)强制创建独立合成层（比will-change更可控） - 动画时长设为偶数秒（如
6s、8s），避免小数帧导致插值误差累积 - 用
animation-timing-function: linear，避免cubic-bezier()在低端设备上计算开销过大
Vue/React 框架中动态控制 will-change 的陷阱
在响应式框架里通过 class 切换控制 will-change（比如 hover 时加、离开时移除），容易触发合成层反复创建销毁。实际测试表明：
-
will-change: transform加在@mouseover事件里 → 滚动卡顿加剧（Chrome 124+ 已确认） - 用
getComputedStyle(el).willChange主动读取 → 触发强制同步布局，得不偿失 - 真正安全的做法：只在初始化滚动动画前静态写死，且生命周期内不修改
2026 年主流框架（Vue 3.5+、React 19）默认禁用运行时 will-change 注入，就是因为它和虚拟 DOM 的 patch 机制存在底层冲突——这点很容易被文档忽略。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
