H5端导航栏高度应固定为44px，因--status-bar-height在H5中无效（值为0），误用会导致贴顶、截断或重叠；三端需用条件编译区分逻辑，H5不适用状态栏适配思维。
uni-app H5端导航栏高度为什么总是“飘”？
因为H5根本没有系统级状态栏，--status-bar-height 在H5里是无效的（值为0），而你却在样式里写了 top: var(--status-bar-height) 或者用它参与计算——结果就是导航栏直接贴顶、被截断、或和内容重叠。这不是bug，是误用变量。
- H5运行在浏览器里，顶部由地址栏/工具栏控制，开发者无法也不该去“适配”它
-
--status-bar-height是App和小程序才真正需要的变量；H5端它不随设备变化，也不反映任何真实安全区 - 很多开发者抄了App或小程序的写法，直接套到H5上，导致iOS Safari下导航栏被顶飞、Android Chrome里留白异常
怎么给H5端设一个靠谱的导航栏高度？
别猜、别算、别依赖动态变量——H5端就用固定值，而且只用一个：44px。
- 这是iOS/Android主流WebView中视觉最协调的高度，也是uni-app官方示例默认采用的值
- 不要用
uni.getSystemInfoSync().statusBarHeight去取值，它在H5返回的是0或错误值 - 如果你用了uView等UI库的
uv-navbar，记得关掉它的placeholder（否则会多占一层空白），自己用padding-top: 44px或margin-top: 44px预留空间 - 若导航栏是
position: fixed，请用top: 0+height: 44px，而不是top: var(--window-top)（这个变量在H5里也不稳定）
三端共用一套导航栏代码时，怎么避免互相干扰？
靠条件编译切逻辑，而不是靠运行时判断平台——后者在H5里容易失效或延迟。
- 用
// #ifdef H5/// #ifdef APP-PLUS/// #ifdef MP-WEIXIN包裹不同逻辑，编译时就剔除无关代码 - H5端导航栏高度写死为44px；App端用
var(--status-bar-height)+ 自定义内容高度（如胶囊按钮区域）；小程序端则必须结合uni.getMenuButtonBoundingClientRect()计算胶囊位置 - 千万别在data里统一定义
navHeight然后靠uni.getSystemInfo异步赋值——H5里这个API不可靠，且页面渲染早于回调，导致首次加载错位
为什么iOS H5里导航栏看起来“被顶上去”了？
不是导航栏动了，是整个页面视口被Safari的“地址栏收起”行为拖动了。
- iOS Safari滚动时会隐藏地址栏，
window.innerHeight变大，但你的fixed导航栏没跟着重定位 - 解决方案不是监听scroll（性能差、不准），而是用CSS的
env(safe-area-inset-top)——但它在H5里支持有限，稳妥做法仍是放弃“沉浸式”，老实用padding-top: 44px加内边距布局 - 如果非要用fixed，务必加
will-change: transform防止渲染抖动，并确保父容器没有transform或perspective干扰层叠上下文
