根本原因是uni-app默认让body滚动，而ios safari对position: fixed的tabbar在body滚动时合成层处理不稳定，导致重排中位置计算延迟或错位；解决方案是禁用body滚动，改用内部容器滚动，并配合transform: translatez(0)等gpu加速补丁。
为什么iOS Safari滚动时tabBar会抖动
根本原因不是CSS写错了，而是uni-app默认让整个body参与滚动，而iOS Safari对position: fixed元素（比如tabBar）在body滚动时的合成层处理不稳定。滚动触发重排时，fixed元素位置计算延迟或错位，视觉上就表现为“抖动”或“卡顿”。这个问题在微信内置浏览器里不明显，是因为它用了不同的渲染策略。
禁用body滚动，改用内部容器滚动
核心思路是把滚动行为从body剥离，交给一个可控的内部<view></view>容器。这样fixed定位的tabBar就能稳定锚定在视口底部，不受页面内容滚动干扰。
- 在根容器（如
<view class="app-container"></view>）上设置height: calc(100vh - var(--tab-bar-height) - env(safe-area-inset-bottom))，预留出tabBar和安全区空间 - 给该容器加
overflow: hidden，彻底切断body滚动能力 - 在子容器（如
<view class="page-content"></view>）上启用滚动：overflow-y: auto; -webkit-overflow-scrolling: touch - 确保tabBar本身用
position: fixed; bottom: 0; left: 0; right: 0;，且z-index足够高
必须加的CSS兼容补丁
仅靠容器滚动还不够。iOS WebKit对fixed元素在滚动上下文中的渲染有隐藏限制，需手动干预：
- 给tabBar父级或自身加
transform: translateZ(0)或will-change: transform，强制GPU加速合成 - 避免在滚动容器内使用
position: fixed的其他元素（比如悬浮按钮），否则会相互干扰 - 移除
body上可能存在的overscroll-behavior: contain或touch-action: manipulation等冲突声明 - 检查是否误启用了
uni.hideTabBar()又立即show，这种快速切换在iOS下极易触发重绘抖动
别忽略的运行时细节
很多抖动实际发生在页面切换或数据加载后，而非单纯滚动时：
- 使用
v-if控制tabBar显隐（而非v-show），避免DOM残留导致布局重算 - 在
onShow生命周期里延迟1帧再更新tabBar选中状态：this.$nextTick(() => this.activeIndex = ...) - 如果用了自定义tabBar组件，确保它在所有tab页面中是同一个实例（通过
App.vue全局挂载或provide/inject），而不是每个页面重复创建 - 真机调试时打开Safari开发者工具的“Rendering → Paint Flashing”，能直接看到抖动是否源于频繁重绘
真正稳定的方案，从来不是堆砌CSS动画去掩盖抖动，而是从滚动归属权开始，把body的控制权收回来——这点在iOS上尤其关键，因为它的fixed渲染逻辑和其他平台根本不在同一套机制里。
