核心是禁用body滚动、改用内部容器滚动，因ios safari对body滚动下fixed元素的合成层处理不稳定；需设根容器height并overflow:hidden，子容器启用-webkit-overflow-scrolling:touch，导航栏用position:fixed且z-index≥999。
固定导航栏不随页面滚动，核心不是“怎么把 navbar 设成 fixed”，而是「让页面内容滚动，而不是整个 body 滚动」。iOS Safari 对 position: fixed 元素在 body 滚动上下文中的合成层处理极不稳定，强行 fixed 在 body 上，必抖、必闪、必错位。
为什么 position: fixed 在 iOS H5 里会失效或抖动
uni-app 默认启用 body 滚动模式，所有页面内容撑开 body 高度，position: fixed 的导航栏实际锚定在 body 视口上 —— 而 iOS WebKit 在 body 滚动时，对 fixed 元素的位置重计算存在延迟和合成层撕裂，尤其在快速滚动、页面切换、软键盘弹出后最明显。
- 不是 CSS 写错了，是滚动容器选错了
- 微信内置浏览器不明显，是因为它绕过了 WebKit 的部分渲染限制
-
transform: translateZ(0)或will-change: transform只能缓解，不能根治
必须用容器滚动替代 body 滚动
把滚动行为从 body 剥离，交给一个内部 <view></view> 容器，导航栏才能真正“钉死”在视口上。
- 根容器（如
<view class="app-container"></view>）设height: calc(100vh - var(--tab-bar-height) - env(safe-area-inset-bottom))，预留底部空间 - 该容器加
overflow: hidden，彻底禁用 body 滚动 - 子容器（如
<view class="page-content"></view>）启用overflow-y: auto; -webkit-overflow-scrolling: touch - 导航栏自身用
position: fixed; top: 0; left: 0; right: 0;，且确保z-index足够高（建议 ≥ 999）
scroll-view 场景下如何避免导航栏被带跑
如果用了 <scroll-view></scroll-view>，它的滚动容器必须有明确高度，否则在小程序和 H5 下都会退回到 body 滚动，导致 fixed 导航栏再次失联。
-
<scroll-view></scroll-view>父容器需设flex: 1; height: 0;（仅 flex + height: 0 才能在小程序中正确撑开） - 不要给
<scroll-view></scroll-view>直接设height: 100%，它在多数平台不生效 - 若导航栏是自定义的（非 pages.json 配置），确保它不在
<scroll-view></scroll-view>内部，也不依赖其滚动事件控制显隐 - 慎用
@scroll动态修改导航栏样式：频繁触发重排可能诱发抖动，优先用 CSSsticky或纯 CSS 过渡
真机调试时容易忽略的运行时陷阱
很多抖动不是发生在静态滚动中，而是由生命周期、DOM 更新或输入事件间接触发的。
- 用
v-if控制导航栏显隐，别用v-show—— 后者残留 DOM 会干扰布局重算 - 在
onShow里更新导航栏状态前，加this.$nextTick(() => {...})，避免状态不同步引发重绘 - 软键盘弹出时，iOS 会强制滚动 input 到可视区，导致 fixed 导航栏位移；可在
pages.json中配"app-plus": {"softinputMode": "adjustResize"}，并监听onPageScroll主动收起键盘 - 开启 Safari 开发者工具的
Rendering → Paint Flashing，一眼识别是否因高频重绘导致抖动
真正稳定的固定导航栏，从来不是靠堆 !important 或多加几层 transform，而是从滚动容器的设计源头切断干扰路径。一旦 body 不再滚动，fixed 就回归本意 —— 锚定视口，纹丝不动。
