iOS Safari 和 WebView 中 fixed 元素滚动抖动是因祖先创建新层叠上下文（transform/filter/opacity<1）致其脱离视口锚定，根本解法是 body 用 height: 100vh + overflow: hidden，由直接子元素接管滚动。
这不是 CSS 写错了，而是 iOS Safari 和多数 WebView（比如微信、QQ、支付宝内置浏览器）在滚动时主动把 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) 都无效——它只对自身生效，救不了被“污染”的祖先链。
iOS Safari 对 body 滚动做了激进优化
WebKit 内核默认用低频采样同步 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 模拟器几乎不复现。
