uni-app解决H5端特定浏览器100vh适配

在实际的H5开发中，全屏适配是个常碰到的难题，尤其是在iOS Safari上。很多开发者会发现，用100vh设置的高度，页面打开时看着正常，滚动一下或切换横屏，底部就开始“缩水”，出现白边，甚至scroll-view都撑不满布局。这背后的原因，并不是CSS写得有问题，而是iOS Safari对视口单位的实现方式有个天生的“缺口”。

为什么H5端100vh在iOS Safari里会“缩水”

iOS Safari的一大特点是地址栏会在用户滚动页面时动态收起或展开——这直接导致了视口高度不断重新计算。但uni-app在加载H5页面时，只读取了一次window.innerHeight的值，后续地址栏的变化它完全不感知。结果是，页面刚打开时高度恰好，但一旦用户操作，底部就会突然塌陷、留白，或者内容撑不满，还原到一种不完整的视觉状态。

用uni.getSystemInfoSync()动态设高度最稳

与其在CSS里死磕100vh，不如直接用Ja vaScript获取真实的可用视口高度，然后动态绑定到元素上。这样做的兼容性目前在H5端是最可靠的方案。具体来说：

• uni.getSystemInfoSync()返回的windowHeight是纯内容区的高度，不含地址栏、状态栏等干扰因素。
• 建议在onLoad和onShow里都调一次，因为部分安卓机型在页面切换后，windowHeight可能不会自动刷新。
• 如果页面包含自定义导航栏或tabbar，需要额外减去对应高度（比如88rpx或100rpx），不能只靠100vh硬性减去。

示例代码：

export default {
  data() {
    return { windowHeight: 0 }
  },
  onLoad() {
    this.setPageHeight()
  },
  onShow() {
    // 防止切页后高度失效
    setTimeout(() => this.setPageHeight(), 100)
  },
  methods: {
    setPageHeight() {
      const info = uni.getSystemInfoSync()
      this.windowHeight = info.windowHeight - 88 // 减去自定义顶部tab高度
    }
  }
}

禁用vh适配，改用rem + 动态根字号

如果你的项目大量使用了rpx或rem单位，并且需要横竖屏之间的平滑切换，那么直接关掉uni-app默认的vh基准，是更彻底的方案。关键在于这几步：

• 在manifest.json里确认没有开启viewport相关的自动适配（特别要避免"scale": true）。
• 在App.vue中手动设置document.documentElement.style.fontSize，用window.innerHeight / 10 + 'px'作为1rem的基准。
• 必须监听resize和orientationchange事件，但iOS Safari上事件触发有时会有延迟，建议套一层setTimeout延时更新。
• 注意：scroll-view内部如果仍使用vh单位，同样会塌陷，所以统一改成rem或px才能彻底解决。

H5端慎用calc(100vh - Xpx)

不少开发者想用CSS减法来“修”高度，比如height: calc(100vh - 44px)。但在H5端，这招容易翻车。原因很简单：

• iOS Safari里100vh本身就不稳定，再减去固定的像素值，误差会被放大。
• 不同机型的状态栏、地址栏高度差异很大（比如iPhone 14 Pro和SE之间能差20px以上），硬编码44px或50px并不可靠。
• 条件编译#ifdef H5虽然能隔离平台，但它解决不了vh自身计算缺陷的问题。
• 真要使用calc，至少得配合env(safe-area-inset-bottom)和--status-bar-height变量，但这些仅对安全区有效，不能解决主视口塌陷的核心问题。

还有一个容易被忽略的点：在H5端，page组件并不是滚动容器，body才是。所以overflow: hidden如果加在.page上是不起作用的，必须作用于html或body才有效——这一点和微信小程序或者APP端的逻辑完全不同。