iOS Safari 中 fixed 元素滚动抖动是因祖先层叠上下文（transform/filter/opacity<1）致其降级为 absolute，叠加 body 滚动采样优化与 100vw 宽度跳变所致；应改用 scroll-container 接管滚动并用 inset: 0 替代 width: 100vw。
这不是 CSS 写错了，而是 iOS Safari（含微信、QQ、支付宝等 WKWebView）在滚动时主动把 position: fixed 元素临时降级为 position: absolute，导致它脱离视口锚定、重绘不同步——抖动是结果，不是原因。
fixed 元素被祖先节点“拖下水”
抖动最常发生在 fixed 元素的任意祖先（哪怕隔了 3 层）写了以下任一声明：
-
transform（包括translateZ(0)、scale(1)） -
filter（哪怕只是filter: blur(0)） -
opacity小于 1（比如opacity: 0.99）
这些都会创建新层叠上下文（stacking context），让 fixed 元素瞬间失去 viewport 基准。此时再给它加 translateZ(0) 都无效——它只对自身生效，救不了被“污染”的祖先链。
body 滚动触发 WebKit 的激进优化
iOS Safari 对 body 滚动做了低频采样同步，而非实时锚定 fixed 元素位置。这在真机上表现为导航栏跳帧、底部按钮“粘不住”。绕过它的唯一可靠方式是：
立即学习“前端免费学习笔记（深入）”；
body { height: 100vh; overflow: hidden; }- 用一个直接子元素（如
.scroll-container）接管滚动：overflow-y: scroll; -webkit-overflow-scrolling: touch; - 该容器必须是
body的**直接子元素**，嵌套过深 iOS 可能忽略
所有内容（含 fixed 导航栏）仍放在 body 里，但滚动行为只发生在这个容器内。
width: 100vw 引发的宽度跳变是“假抖动”
用 width: 100vw 做全屏 fixed 元素时，弹窗打开触发 body { overflow: hidden } → 滚动条消失 → 100vw 突然变大 ≈ 15px → 元素左移，视觉上像“抽搐”。
- 更稳的写法：改用
inset: 0（现代浏览器支持良好），或width: 100%; left: 0 - 防滚动条跳变：给
body加padding-right: calc(100vw - 100%)，让滚动条始终占位
真正顽固的抖动，往往不是缺某个 CSS 属性
而是多个隐性干扰叠加：祖先 transform + 内部 text-shadow + body 滚动 + 100vw 宽度——任何单点修复都压不住。
优先切滚动容器，再逐项排查祖先链和尺寸声明。真机测试时务必关掉系统“减少动画”，并在微信、QQ 等 WebView 中单独验证；DevTools 模拟器几乎不复现。
