给长列表项加 will-change 会严重拖慢滚动性能，因其强制创建过多合成层导致 GPU 内存激增；正确做法仅对真实用 transform 滚动的容器（如 .scroll-content）动态启用，并配以 translateZ(0)。
给长列表项加 will-change 不仅无效，反而显著拖慢滚动性能——它不是加速开关，而是合成层创建提示，用错对象就会引爆 GPU 内存。
为什么给 li 或 .item 加 will-change: transform 更卡
浏览器对每个启用 will-change: transform 的元素都会尝试提升为独立合成层。一屏显示 15 个列表项，滚动中常驻 20+ 个，等于同时塞给 GPU 20 多个图层。中低端安卓机显存紧张，极易触发纹理上传阻塞、图层抖动，帧率从 60fps 直降到 20fps 以下。
更关键的是：will-change 不会改变滚动行为本身——原生 overflow-y: auto 容器的滚动由浏览器底层合成器直接处理，无需、也不该靠手动升层“加速”。DevTools 控制台还会报出 [Violation] will-change memory consumption 警告。
- 不要写
.item { will-change: transform; }这类全局规则 - 避免在 Vue/React 的
v-for或map()渲染循环里静态加该类 - 即使加了，也绝不能配合
top、margin-top或未设transform的动画——这些属性根本进不了合成流水线
真正该加 will-change 的地方只有一个
只对「承载真实位移逻辑」的容器设置，且必须满足两个硬条件：该容器有明确尺寸 + 正在用 transform 做滚动模拟（比如虚拟滚动的 .scroll-content 或 JS 驱动轮播的 .carousel-track）。
立即学习“前端免费学习笔记（深入）”；
正确写法示例：
.scroll-content {
will-change: transform;
transform: translateZ(0); /* 必须有真实 transform，否则提示被忽略 */
}
- 加在父滚动容器（如
.list-container）上是错的——信号发错目标，图层建得过大 - 加在
will-change: scroll-position上完全无效——该值未被任何主流浏览器支持 - 必须搭配真实
transform变化，哪怕只是translateZ(0)，否则浏览器直接无视
比 will-change 优先级高得多的三件事
90% 的长列表卡顿根源不在渲染层，而在主线程被拖住或布局反复重算。加 will-change 前，请先确认：
- 滚动监听是否用了
{ passive: true }—— iOS Safari 不加这个，惯性滚动直接被禁用 - 有没有在
scroll回调里读取scrollTop、getBoundingClientRect()或写style—— 这会强制同步回流，一滚就掉帧 - 图片是否设了宽高 +
loading="lazy"—— 每张图加载都可能触发重排，影响远超will-change的开销
虚拟滚动（如 react-window）把 DOM 节点数从几千压到 10–20 个，才是治本方案；will-change 只是在这之上做微调，不是替代品。
动态控制 will-change 的安全写法
如果真要用，必须动态启停，且清理时机要准。静态写死等于长期占着 GPU 内存，尤其在移动端容易引发白屏或偶发渲染中断。
推荐 JS 控制模式：
// 开始滚动前一刻启用
container.addEventListener('scroll', () => {
scrollContent.style.willChange = 'transform';
}, { once: true });
<p>// 动画结束后两帧再清理（防闪屏）
requestAnimationFrame(() => {
requestAnimationFrame(() => {
scrollContent.style.willChange = 'auto';
});
});
- 别用
:hover或@media触发will-change—— 悬停瞬间升层太晚，卡顿就在那一帧 - 别依赖
getComputedStyle(el).willChange做判断——读取本身就会触发同步布局 - 用 Chrome DevTools → Layers 面板验证：图层数应稳定在 3～5 层，超过 8 层就要立刻排查
最常被忽略的点是清理不及时——线上问题里，70% 的 will-change 相关内存泄漏，都源于加了没删。
