will-change: transform 对 fixed 抖动基本无效，因滚动缩放不改变元素自身 transform 值；真正触发合成层需显式写 transform: translateZ(0) 或 translate3d(0,0,0)，并避免父容器干扰。
加 will-change: transform 不能防止 fixed 元素滚动抖动，反而可能让问题更隐蔽——它只在元素**自身即将执行 transform** 时起作用，而页面滚动或缩放触发的是视口级变换，不是该元素的属性变更。
为什么 will-change: transform 对 fixed 抖动基本无效
浏览器对 position: fixed 的合成处理依赖于视口坐标系，而 will-change: transform 的提示对象是“本元素将发生 transform 变化”。但滚动、缩放、地址栏收放这些行为，不会修改该元素的 transform 值，所以浏览器大概率忽略这个声明。
- Chrome 95+ 已在 DevTools Console 明确警告：
will-change: transform is deprecated for non-transforming elements - 如果元素没写
transform: translateZ(0)或类似值，will-change单独存在几乎不触发图层提升 - 滥用会导致内存占用上升，尤其在频繁增删的弹窗、Tooltip 等场景中
真正能触发 GPU 合成层的写法（不是靠 will-change）
要让 fixed 元素稳定进独立合成层，必须显式声明一个不影响布局的 transform，并配合副作用更小的属性：
- 必须写
transform: translateZ(0)或transform: translate3d(0, 0, 0)—— 这才是触发硬件加速的开关 - 推荐追加
backface-visibility: hidden：比translateZ(0)更轻量，且能避免部分安卓 WebView 的图层降级 - 不要给父容器加 transform/filter/opacity < 1，否则 fixed 元素会脱离视口基准，降级为 relative 定位行为
- 避免在 fixed 元素内部用
width: 100vw或right: 0；改用inset: 0（现代支持良好）或固定宽高 +transform微调
移动端 Safari 的抖动根本不是 GPU 问题
iOS Safari 中 fixed 滚动抽搐，本质是 WebKit 主动把 fixed 元素从视口锚定中剥离，再靠低频采样去同步位置。此时加任何 GPU 相关声明都治标不治本。
立即学习“前端免费学习笔记（深入）”；
- 最稳解法是把滚动容器从
body移到子元素：body { height: 100vh; overflow: hidden; }+.scroll-container { height: 100vh; overflow-y: scroll; -webkit-overflow-scrolling: touch; } - 若必须保留
body滚动，可尝试viewport-fit=cover+env(safe-area-inset-top)配合固定高度，但需注意 iOS 16.4+ 才完全支持calc(100vw - 100%) -
-webkit-overflow-scrolling: touch是开关，不加就卡顿，加了才启用原生惯性——但它只对设置了overflow的容器生效，对body本身无效
抖动还可能是 body 宽度突变引起的“假抖动”
很多人以为是 fixed 元素在动，其实是 body 因滚动条出现/消失导致宽度跳变（约 15px），所有非 fixed 内容被整体“左抽”了一下。
- 修复方式是让滚动条始终占位：
body { padding-right: calc(100vw - 100%); } - 配合
body.modal-open { overflow: hidden; }，视觉上隐藏滚动条但宽度不变 - 老版 Safari（iOS 14 以下）不支持
calc(100vw - 100%)动态计算，得用 JS 测一次后写死：document.body.style.paddingRight = '17px' - 别用
margin-right替代——它不参与 box-sizing，撑不开容器宽度
真正需要关注的，从来不是“要不要加 will-change”，而是 fixed 元素是否还在视口坐标系里、body 宽度是否稳定、滚动是否被正确隔离——这些细节一漏，再多 GPU 加速也压不住抖动。
