h5端--status-bar-height恒为0，因其无系统状态栏概念；导航栏高度应固定为44px，通过条件编译区分平台，避免依赖不可靠的h5运行时api。
--status-bar-height 在 H5 端就是无效的，值恒为 0。这不是 bug，是设计如此。H5 没有系统状态栏概念，强行用它会导致导航栏贴顶、内容被截断或布局错乱。
为什么 H5 里 --status-bar-height 总是 0
H5 运行在浏览器中，顶部由地址栏/工具栏控制，不是原生系统层；--status-bar-height 是 App 和小程序才注入的 CSS 变量，H5 编译时根本不会生成这个变量。很多项目直接抄小程序写法：top: var(--status-bar-height)，结果在 iOS Safari 下导航栏直接“飞”到屏幕最顶上。
- uni.getSystemInfoSync().statusBarHeight 在 H5 返回 0 或 NaN，不可信
- env(safe-area-inset-top) 在 H5 大部分浏览器不支持，返回 undefined 或 0
- 试图用 JS 动态计算“状态栏高度”属于无源之水——浏览器根本不暴露该信息
H5 端导航栏高度必须写死为 44px
这不是妥协，而是事实标准：iOS/Android 主流 WebView 中，视觉协调、交互舒适、与系统控件对齐的最佳高度就是 44px。uni-app 官方示例、uView、uni-ui 的 H5 导航栏默认都采用此值。
- 固定写法示例：
height: 44px（非 fixed 元素）或top: 0; height: 44px（fixed 导航栏） - 若用
padding-top预留空间，也必须是padding-top: 44px，别算、别猜、别依赖任何运行时值 - 使用 uView 的
uv-navbar时，务必关闭placeholder，否则会额外多占一层空白
三端共用代码时怎么避免 H5 被带偏
靠运行时判断平台（如 uni.getSystemInfoSync().platform === 'h5'）容易出问题：H5 的 API 不可靠，且页面渲染早于回调，首次加载必错位。唯一稳妥方式是条件编译，在编译阶段就剔除无关逻辑。
-
// #ifdef H5块内只写height: 44px和基础样式 -
// #ifdef APP-PLUS块内用var(--status-bar-height)+ 自定义内容高度 -
// #ifdef MP-WEIXIN块内必须结合uni.getMenuButtonBoundingClientRect()计算胶囊位置 - 绝对不要在
data里统一定义navHeight并异步赋值——H5 里这一步注定失败
最容易被忽略的细节
很多人改完样式仍出问题，往往卡在两个地方：一是用了 top: var(--window-top)，这个变量在 H5 里也不稳定；二是自定义导航栏容器（比如 .custom-nav）被其他 CSS 覆盖，比如父级设置了 overflow: hidden 或误加了 transform，导致高度计算失效。真机调试时，直接 inspect 元素看 computed height 和 padding 是否真的生效，比查文档更快。
