应优先使用 env.safearea.top 而非 statusbarheight；因后者仅返回状态栏高度，不包含导航栏容器、阴影、安全区偏移等，易致刘海屏下白边或偏移；env.safearea.top 是小程序 onload 后注入的真实顶部安全距离，需条件编译兼容。
直接用 statusBarHeight 计算导航栏位置，90% 的白边问题都出在这儿——它只返回状态栏本身高度，不包含安全区、导航栏容器内边距、阴影或刘海屏下系统预留的完整顶部空间。
为什么 statusBarHeight 在小程序里不可靠
微信/支付宝小程序中，navigationStyle: "custom" 后，系统仍会渲染一个「导航栏占位区域」，其真实高度通常是 statusBarHeight 的 2～2.5 倍（iOS 15+ 常见 88px～96px）。而 uni.getSystemInfoSync().statusBarHeight 返回的只是纯状态栏（如 44px），完全没考虑胶囊按钮、分割线、安全区上边界偏移等。
- 华为 P 系列等安卓刘海机型，
statusBarHeight可能滞后或固定为 24px，但实际安全区 top 已达 56px - 小程序环境里，
env.safeArea.top是唯一由容器注入的真实值，必须在onLoad后读取 -
onLaunch或created阶段访问env会是undefined，因为此时页面上下文未就绪
小程序端必须用 env.safeArea.top 获取顶部安全距离
微信、支付宝、QQ 小程序会在页面 onLoad 后自动向全局注入 env 对象，其中 env.safeArea.top 是当前设备顶部安全区真实像素值，无需计算、不依赖系统 API，且与胶囊按钮位置天然对齐。
- 不要写
top: calc(var(--status-bar-height) + 44px)—— H5 里--status-bar-height是 0，小程序里它也不等于env.safeArea.top - 正确姿势：在
onLoad中直接取值，例如this.navTop = uni.getEnv().safeArea?.top || 44 - 需搭配条件编译，避免 H5 报错：
// #ifdef MP-WEIXIN包裹读取逻辑 - 若要兼容旧版微信（uni.getMenuButtonBoundingClientRect() 的
top值更稳妥
H5 端根本不用适配状态栏，写死 44px 就行
H5 运行在浏览器里，没有系统状态栏概念，--status-bar-height 和 uni.getSystemInfoSync().statusBarHeight 在 H5 下一律返回 0 或无效值。任何基于它的动态计算都会导致导航栏贴顶、截断或首次渲染错位。
- 导航栏样式直接写
height: 44px; top: 0;，别用top: var(--status-bar-height) - 如果用了
uView的uv-navbar，关掉placeholder属性，否则会多一层空白 - 三端共用导航栏组件时，用
// #ifdef H5单独写固定高度逻辑，编译时剔除其他平台代码 - 绝对不要在
data里异步请求statusBarHeight再赋值给navHeight—— H5 渲染早于回调，首屏必错位
安卓 App 端底部白边和顶部错位要分开处理
安卓的「白边」常被误认为是状态栏问题，其实多数来自底部安全区或虚拟导航栏残留。顶部异常则多因 immersed: true 配置后，statusBarHeight 未重算，或未监听 resize 事件应对横屏/分屏变化。
- 底部白边优先用 manifest.json 配置：
"app-plus": {"safearea": {"bottom": {"offset": "none"}}} - 顶部若仍有偏移，检查是否开启了沉浸式：
"statusbar": {"immersed": true}，开启后statusBarHeight不再可靠，应改用env.safeArea?.top（仅限 3.2.14+） - Android 13+ 和分屏模式下，
onResize必须监听，getSystemInfoSync返回值可能严重滞后 - 真机调试时，华为/小米/OPPO 对安全区的实现差异极大，不能只靠一个值覆盖全部机型
最易被忽略的一点：安全区不是“一次性配置”，它会随横竖屏切换、分屏、刘海区域透明化等动态变化；所有依赖它的布局，必须绑定响应式更新，而不是 onLoad 读一次就完事。
