应为 statusbarheight 设置合理默认值：ios 用 44、普通安卓用 24、h5 用 0，并在 data 初始化时赋值，避免依赖单次 api 调用结果；app 端可在 mounted 中同步覆盖，h5 禁用 --status-bar-height 变量。
uni.getSystemInfoSync().statusBarHeight 返回 0 或 undefined 怎么办
直接用 uni.getSystemInfoSync().statusBarHeight 在部分平台（尤其是 App 启动初期、H5、某些低版本安卓 WebView）会返回 0 或 undefined，不是 API 坏了，而是系统信息还没就绪或 H5 本就不提供该值。硬等或重试不可靠，必须设合理 fallback。
推荐做法是封装一层带默认值的获取逻辑，不依赖单次调用结果：
- 优先用
uni.getSystemInfoSync()同步取值，捕获异常后立即 fallback - 默认值按设备类型区分：iOS 普遍用
44（含刘海），普通安卓用24，H5 统一用0（因无真实状态栏） - 若项目已知目标设备集中（如只上 iOS App），可简化为固定
44，避免运行时判断开销
App 端 mounted 中调用仍拿不到？检查生命周期时机
在 onLoad 或 onShow 里调 uni.getSystemInfo 异步回调，常因页面渲染早于系统信息就绪，导致 this.statusBarHeight 还是初始值 0。这不是数据没拿到，是赋值太晚、样式已计算完毕。
正确姿势是提前在 created 或 beforeCreate 阶段同步初始化，并允许后续覆盖：
- data 初始化时就设默认值：
statusBarHeight: uni.getSystemInfoSync()?.statusBarHeight || 44 - 避免在
onLoad里异步更新后仅靠响应式驱动样式，改用:style="{ paddingTop: statusBarHeight + 'px' }"确保重绘 - App 端若需更高精度（如全面屏适配），可在
mounted再调一次同步 API 覆盖，但默认值必须存在
H5 端别碰 --status-bar-height 变量
H5 运行在浏览器中，--status-bar-height 自定义 CSS 变量在 H5 下始终为 0，强行用它做 top 或 padding-top 计算，会导致导航栏贴顶、内容被截断。这不是兼容性问题，是概念误用。
解决方式极简：
- H5 端导航栏高度固定用
44px，写死在 class 或内联 style 里 - 用条件编译隔离：
#ifdef H5块内不读任何状态栏相关 API，也不引用--status-bar-height - 若用 uView 的
uv-navbar，务必关掉placeholder，否则会叠加一层空白
小程序端胶囊按钮信息缺失时的导航栏高度兜底
自定义导航栏时，常靠 uni.getMenuButtonBoundingClientRect() 和 statusBarHeight 推算总高度。但该 API 在部分低端安卓机或调试环境可能返回空对象或抛错，导致 menuButtonInfo.top 为 undefined，整个计算链断裂。
安全做法是双层 fallback：
- 先确保
statusBarHeight有值（见第一点） - 再对
menuButtonInfo做存在性校验：menuButtonInfo?.height && menuButtonInfo?.top，否则用经验公式statusBarHeight + 44（状态栏 + 标题栏） - 最终导航栏高度建议不低于
88px（iOS 全面屏常见值），避免内容挤压
状态栏高度不是“取一次就能用一辈子”的静态值，尤其在跨端场景下，它的来源、时效性、语义都不同。真正关键的不是“怎么取”，而是“取不到时系统是否还能稳住布局”。默认值不是补丁，是设计前提。
