ios safari中tabbar抖动的根本原因是wkwebview对position: fixed的渲染限制，最稳定解法是禁用body滚动、改用内部容器滚动，并必须使用pages.json配置的原生tabbar。
为什么iOS Safari里tabBar会抖动
根本原因是iOS Safari对position: fixed的实现不一致：当页面内容滚动时，原生底部导航栏（或你用fixed模拟的tabBar）会被强制重绘，触发GPU层切换，造成视觉抖动。这不是uni-app bug，而是WKWebView渲染管线的已知限制。
禁用body滚动，改用内部容器滚动
这是最稳定、上线项目验证过的解法。核心是让滚动发生在子容器内，避免触发body级重排，从而绕过iOS对fixed元素的异常处理。
- 在根容器（如
<view class="app-wrapper"></view>）上设置height: calc(100vh - var(--tab-bar-height) - env(safe-area-inset-bottom))，并加overflow: hidden - 所有页面内容包裹进一个
<scroll-view></scroll-view>或<div class="page-content">，设<code>height: 100%+overflow-y: auto+-webkit-overflow-scrolling: touch - 务必给tabBar自身加
z-index: 999和position: fixed，且高度需与CSS变量--tab-bar-height严格一致（如50px） - 在
pages.json中配置"tabBar"字段，哪怕只用默认样式，也必须存在 - 若需差异化UI（比如骑手/用户两套tab），用
uni.hideTabBar()+uni.showTabBar()动态控制显隐，而不是彻底替换 - 避免在
onLoad里调uni.hideTabBar({animate: false})——动画关闭反而加剧抖动，留默认动画更稳
uni-app H5端tabBar必须用原生配置
别手写fixed组件——哪怕样式再像，只要不是pages.json里声明的原生tabBar，iOS下就大概率抖动。uni-app的H5端tabBar渲染逻辑依赖平台原生能力，自定义等于放弃这个优化路径。
慎用transform硬件加速
网上流传的加-webkit-transform-style: preserve-3d或translateZ(0)对iOS Safari tabBar抖动基本无效，甚至可能因强制创建新图层而加重内存压力。
真正起作用的是滚动容器隔离 + 原生tabBar保底。复杂交互（如带滚动通知的顶部栏）才需要考虑transform，但底部tabBar场景下，它只是干扰项。
容易被忽略的一点：iOS真机调试必须用Safari远程调试器看Layers面板，确认tabBar是否真的跑在独立合成层——很多“看似修复”的方案其实没生效。
