env(safe-area-inset-top)是目前最可靠的CSS原生方案，无需JS、不依赖运行时环境，但仅在iOS Safari及部分安卓浏览器中有效，且需配合viewport-fit=cover和正确@supports检测，并必须设置fallback值（如20px）以保障兼容性。
用 env(safe-area-inset-top) 获取状态栏高度最可靠
直接读取系统状态栏高度，env(safe-area-inset-top) 是目前唯一无需 JS、不依赖运行时环境、且能跨平台（iOS/Android）生效的 CSS 原生方案。它返回的是逻辑像素值，单位就是 px，可直接用于 padding-top 或 margin-top。
常见错误是只写 padding-top: env(safe-area-inset-top) 却没加 fallback：老版本 Safari（
- 必须搭配 fallback 值，例如：
padding-top: 20px; padding-top: env(safe-area-inset-top); - 不能在内联样式里用 ——
style="padding-top: env(safe-area-inset-top)"在多数 WebView 中无效 - 仅对根元素或固定定位的头部生效更稳定；避免套在多层嵌套的 flex 容器里，某些安卓 X5 内核会计算错误
plus.navigator.getStatusbarHeight() 的调用时机陷阱
这个 5+ API 确实返回真实像素值，但必须等 plusready 事件触发后才能调用。如果在 DOMContentLoaded 甚至 load 阶段就执行，大概率返回 0 或 undefined —— 因为此时 5+ 运行环境还没初始化完。
更隐蔽的问题是「闪动」：页面先按无状态栏渲染，再 JS 注入 padding-top，造成头部跳动。这不是 bug，是 DOM 渲染顺序决定的。
立即学习“前端免费学习笔记（深入）”；
- 正确做法：在
plusready回调里获取高度，并立即更新对应 DOM 元素的style.paddingTop - 不要用
document.write插入 style 标签，H5+ 环境下可能阻塞渲染 - 若需服务端预判，可解析
navigator.userAgent中的Immersed/\d+字段，但仅限 HBuilderX 打包的 App，其他环境不保证存在
为什么 media query 无法检测沉浸式状态栏
媒体查询只能响应视口尺寸、横竖屏、DPR 等设备能力信号，而沉浸式状态栏是应用级配置行为，和屏幕物理属性无关。比如同一台 iPhone，在微信内置浏览器里永远非沉浸式，但在你打包的 App 里可以开启 —— 两者 viewport 宽度完全一致，@media 根本无法区分。
试图用 @supports (padding-top: env(safe-area-inset-top)) 做降级也不靠谱：它只测 CSS 函数支持性，不反映当前是否真处于沉浸式上下文（比如用户关闭了 manifest 配置，env() 仍可用，但值为 0）。
- 真正需要判断“是否启用沉浸式”，得靠运行时 JS 检测：
plus.navigator.isImmersedStatusbar()（H5+）或uni.getSystemInfoSync().statusBarHeight > 20（uni-app） - 纯 Web 页面（非打包 App）根本无法开启沉浸式，
env(safe-area-inset-top)只在 iOS Safari 和少数安卓厂商浏览器中有效，且仅响应刘海/挖孔，不响应“透明状态栏”设置
manifest.json 里 "immersed": true 不生效的三个原因
写了配置却没效果，90% 是卡在这三处：
- 没在 HBuilderX 里重新「发行」或「真机运行」—— 修改
manifest.json后必须重新打包，热刷新不触发 native 层配置更新 - Android 设备低于 4.4（API 19），
immersed被直接忽略，plus.navigator.isImmersedStatusbar()返回false - iOS 上未同时设置
"style": "light"或"dark"，某些旧版 iOS 会因样式缺失拒绝启用沉浸式（尤其深色模式下文字不可见时）
最易被忽略的是：这个配置只影响原生容器层，对 webview 内容无强制约束力。CSS 仍需主动适配，否则即使状态栏透明了，你的 header 也会被顶到屏幕外。
