禁用 scroll-behavior: smooth 能缓解 fixed 抖动，因其与抖动无因果关系，仅影响锚点跳转动画；iOS 微信 fixed 抖动主因是滚动过程中视口坐标同步延迟，禁用可避免干扰节流逻辑。
为什么禁用 scroll-behavior: smooth 能缓解 fixed 抖动
因为 scroll-behavior: smooth 和 fixed 定位抖动根本不在同一个渲染阶段。它只影响锚点跳转或 scrollIntoView() 的缓动动画，而 iOS 微信（基于 WKWebView）的 fixed 抖动发生在持续滚动过程中——此时浏览器正在降级合成层、延迟同步视口坐标。加了 smooth 反而可能干扰滚动事件节流逻辑，让位置采样更不及时。
禁用平滑滚动的实际操作步骤
这不是“关掉就完事”，而是要精准移除它对滚动上下文的影响：
- 检查全局 CSS 是否写了
html { scroll-behavior: smooth; }或body { scroll-behavior: smooth; }，直接删掉 - 避免在可滚动容器上设置
scroll-behavior，哪怕只是scroll-behavior: auto也可能触发 Safari 的非预期合成策略 - 如果用了
scrollIntoView({ behavior: 'smooth' })，改用{ behavior: 'auto' }；iOS 微信里 smooth 行为本身就不稳定，且和 fixed 抖动无因果关系 - 不要试图用
scroll-behavior配合transform: translateZ(0)“双保险”——前者管动画，后者管图层，混用反而增加合成判断负担
禁用后仍抖动？说明问题不在这里
禁用 scroll-behavior 是个快速排除项，但 iOS 微信里 fixed 抖动的主因通常是：
-
body没设height: 100vh且overflow: hidden，导致滚动容器边界模糊 - fixed 元素父级有
transform、filter或opacity，意外创建了层叠上下文，隔离了合成行为 - 页面存在
input或textarea，软键盘弹起时 viewport 缩放重排，fixed 元素位置重算失败 - 用了第三方滚动库（如 iScroll），但没配
preventDefaultException: { tagName: /^(INPUT|TEXTAREA|BUTTON|SELECT)$/ }，拦截了原生 focus 流
真正稳的解法不是禁用，而是绕开 body 滚动
禁用 scroll-behavior 只是止痛药。iOS 微信里最可靠的方案，是把滚动容器从 body 移到内部 div，并启用 -webkit-overflow-scrolling: touch：
立即学习“前端免费学习笔记（深入）”；
确保 .scroll-container 是 body 的**直接子元素**，且满足：height: 100vh、overflow-y: scroll、-webkit-overflow-scrolling: touch。所有内容（包括 fixed 导航栏）都放在 body 下，但实际滚动的是这个 div —— 此时 fixed 才真正在视口上“固定”。
这个结构下，scroll-behavior 压根没机会生效，抖动自然消失。但要注意：-webkit-overflow-scrolling: touch 必须加，不加滚动会卡顿；且不能嵌套太深，否则 WKWebView 可能忽略该属性。
