移动端fixed抖动主因是ios safari等将fixed临时降级为absolute，导致脱离视口锚定；加translatez(0)无效常见于祖先含transform/filter/opacity
移动端 position: fixed 抖动不是写法错误，而是 iOS Safari（含微信、QQ 等 WKWebView）和部分安卓旧 WebView 主动降级定位策略导致的——滚动时把 fixed 临时当成 absolute 处理，脱离视口锚定，重绘不同步。
为什么加了 translateZ(0) 还抖
常见漏点不是 transform 没加，而是触发条件被破坏：
-
fixed元素的任意祖先写了transform、filter或opacity ，创建了新堆叠上下文，<code>fixed直接退化为 relative 定位 -
translateZ(0)加在父容器上（比如body），而非fixed元素自身——它只对fixed或absolute元素生效 - 元素内部用了
text-shadow、大border-radius或渐变背景，Safari 主动降级回 CPU 渲染 - 混用
transition，尤其在 iOS 15+ 上引发合成层反复升降 - 在微信、QQ 等 WebView 中测试——它们内核比系统 Safari 更老，
translateZ(0)基本无效
为什么 will-change: transform 基本没用
滚动不改变该元素自身的 transform 值，浏览器根本不会响应这个提示：
小红书长文-谷歌浏览器
下载
在 Linux 上通过 Chrome 挂载/VNC 自动发布小红书长笔记。Agent 撰写标题和正文后执行 xhs_publish.sh --publish --submit，触发小红书发布。
-
will-change只在元素**即将执行 transform 动画**时起作用，而滚动是视口级变换，和元素属性无关 - Chrome 95+ 已在控制台明确警告：
will-change: transform is deprecated for non-transforming elements - 单独写
will-change: transform不会触发图层提升，必须搭配transform: translateZ(0)才有效 - 滥用还会抬高内存占用，尤其在频繁增删的弹窗场景中
真正稳的解法：把滚动从 body 移到子容器
绕过 WebKit 对 fixed 的“优化”本身，是最小副作用、最高兼容性的路径：
-
body { height: 100vh; overflow: hidden; }—— 切断body滚动通路 -
.scroll-container { height: 100vh; overflow-y: scroll; -webkit-overflow-scrolling: touch; }—— 必须加这句，否则滚动卡顿；且必须是body的**直接子元素** - 所有内容（包括
fixed导航栏、按钮）仍放在body下，只是实际滚动由这个div承担 - 防滚动条消失导致的“假抖动”：
body { padding-right: calc(100vw - 100%); }（Safari 16.4+ 支持）；老版本需 JS 首次检测后写死：document.body.style.paddingRight = '17px';
复杂点在于：iOS 对 -webkit-overflow-scrolling: touch 的识别极其敏感，嵌套一层就可能失效；env(safe-area-inset-bottom) 在键盘弹出时也会动态变化，fixed 元素若依赖它做 bottom 定位，仍需 JS 修正。这些细节真机一试便知，模拟器往往测不出来。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
