will-change对原生页面滚动（body/html/overflow:auto容器）基本无效且易致卡顿，仅在js驱动的transform模拟滚动中有效，须严格配合touchstart/touchend动态开关；真正起效的是passive监听、避免同步回流等关键优化。
will-change 对原生页面滚动（body、html 或 overflow: auto 容器）基本无效，加了反而更卡；它只在 JS 驱动的 transform 模拟滚动中起作用，且必须动态开关。
为什么给滚动容器加 will-change: scroll-position 没用还更卡
浏览器对 scroll-position 的支持极有限：Chrome 和 Safari 均不响应该值用于优化原生滚动。你看到的“加了变顺”，大概率是巧合或误判——真正起效的是同时做的其他改动（比如加了 { passive: true }、去掉了 getBoundingClientRect()）。常见副作用包括：
-
body或html上设will-change: scroll-position会强制创建全屏合成图层，中低端安卓机图层数超 6～7 个后，纹理上传阻塞，scroll事件回调延迟升高 - iOS Safari 可能直接忽略，或触发合成器中断，出现瞬时白屏
- 若该元素带
border-radius、overflow: hidden或filter，浏览器会回退到软件渲染，will-change彻底失效
什么场景下 will-change 真正有用
仅当满足全部以下条件时，will-change 才可能带来可测收益：
- 滚动不是靠
overflow: auto，而是由 JS 在touchmove中实时更新element.style.transform（例如手写滑动列表、轮播图、视差滚动） - 该元素当前未被自动升层（DevTools Layers 面板里没绿色边框），且没配
transform: translateZ(0) - 已确认首帧延迟 > 16ms，瓶颈在图层未提升（Performance 面板显示“Layerize”阶段耗时高）
此时可在 touchstart 阶段设：element.style.willChange = 'transform'，并在 touchend 或 transitionend 后立刻设回 'auto'。
比 will-change 更关键的三件事
90% 的滚动卡顿根源不在图层，而在主线程被阻塞。优先检查并修复：
- 滚动监听必须传
{ passive: true }：window.addEventListener('scroll', handler, { passive: true }) - 禁止在
scroll回调里读取scrollTop、getBoundingClientRect()或写style.top——这会强制同步回流 - 用
transform替代top/left更新定位，并在动画触发时动态加will-change: transform，结束即清
记住：will-change 不是写死在 CSS 里的长期配置，而是一个需要精确控制生命周期的临时提示。加得早、去得晚、用错对象，效果都等于零——甚至负向。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
