应优先使用 env.safearea.top 获取真实导航栏高度，因其融合状态栏、导航栏阴影及胶囊间距；h5 端用 css env(safe-area-inset-top) 更稳定，避免 js 硬编码导致多端适配失效。
直接用 windowHeight 和 screenHeight 差值不靠谱
很多人以为「导航栏高度 = screenHeight - windowHeight」，但这个算式在多数场景下会出错。原因很实际：screenHeight 是物理屏幕总高（含状态栏、底部指示条、虚拟导航键），而 windowHeight 在 H5 是视口高度，在小程序里是「扣除系统导航栏 + 状态栏后的可用渲染区」——但它不包含自定义导航栏的占位空间，也不反映胶囊按钮带来的额外偏移。尤其在 iOS 15+ 或华为/小米刘海屏上，差值可能忽大忽小，甚至为负。
微信/支付宝小程序必须依赖 env.safeArea 或 getMenuButtonBoundingClientRect
小程序平台（微信、支付宝、QQ）在 onLoad 后会向页面注入 env 对象，其中 env.safeArea.top 是当前设备顶部安全区真实起始位置（单位 px），这才是你该对齐的基准线。它比 statusBarHeight 更准，因为已融合状态栏、导航栏阴影、胶囊间距等所有容器层逻辑。
- 不能在
created或mounted里读 —— 此时env还没注入，取出来是undefined - 必须在
onLoad或之后调用，且需加条件编译：如#ifdef MP-WEIXIN - fallback 方案：当
env.safeArea?.top不可用时，再用getMenuButtonBoundingClientRect()计算：custom.top + (custom.top - statusBarHeight)，即「胶囊上边距 + 上边距与状态栏的差值」
statusBarHeight 只是拼图的一小块，不是导航栏总高
statusBarHeight 仅表示状态栏本身（iOS 通常 44px，Android 多为 24–32px），但原生导航栏或自定义导航栏实际占用高度远不止于此。比如微信小程序启用 "navigationStyle": "custom" 后，系统仍会预留一块区域（常达 88–96px），这块区域由状态栏 + 导航栏容器内边距 + 胶囊上下留白共同构成。硬写死 statusBarHeight + 44 在 iPhone 14 Pro 或华为 Mate 50 上大概率偏高或偏低。
- Android 端
titleBarHeight在支付宝小程序中可用，但微信不提供 - iOS 端不要信
platform === 'ios'就加 44px —— iOS 15 后很多机型导航栏变高，且安全区 top 值已动态调整 - 如果用了自定义导航栏组件，建议把高度计算逻辑封装成 mixin 或 composables，避免每页重复判断
H5 端用 CSS env(safe-area-inset-top)，别 JS 算
H5 没有 env.safeArea，但支持 CSS 环境变量 env(safe-area-inset-top)。直接在自定义导航栏样式里写 padding-top: env(safe-area-inset-top); 即可自动对齐，比 JS 获取 statusBarHeight 再 setStyle 更稳定，也规避了横竖屏切换时 JS 未及时响应的问题。
- 注意加 fallback：
padding-top: 20px; padding-top: env(safe-area-inset-top); - 不要在 JS 里用
getComputedStyle去读这个值 —— 它返回的是字符串（如"20px"），且某些浏览器不支持 runtime 读取 - 若需 JS 中用该值（比如做动画），建议用
matchMedia监听prefers-reduced-motion同时监听安全区变化，但实际项目中极少需要
真正难的不是算出一个数字，而是理解「导航栏高度」在不同平台根本不是一个固定概念：它是容器层、渲染层、安全区规则、甚至用户系统设置（如安卓隐藏导航栏）共同作用的结果。每次你写死一个像素值，都可能在某个新机型上失效。所以优先走平台原生注入机制（env.safeArea / env(safe-area-inset-top)），其次才用 API 组合兜底。
