最稳方案是用 @supports (-webkit-touch-callout: none) 包裹 env(safe-area-inset-top)，作用于 banner 父容器而非 body，并监听 resize 强制重绘以应对横竖屏及分屏突变。
直接加 padding-top 到 body 或主容器，但必须用 @supports (-webkit-touch-callout: none) 包裹 env(safe-area-inset-top)，否则在非 iOS WebKit 浏览器里会失效甚至破坏布局。
为什么 env(safe-area-inset-top) 不能裸写
这个变量只在 iOS Safari、部分新版 Chrome/Edge（需开启实验性功能）中返回有效值；在旧版 Android WebView、桌面浏览器或微信内置浏览器里，它要么返回空值，要么被忽略——结果就是 Banner 文字照常被状态栏盖住，而开发者还查不出错在哪。
更危险的是：@supports (padding-top: env(safe-area-inset-top)) 这种检测方式在 Safari 中也常返回 false，不可靠。目前最稳的识别方式仍是：@supports (-webkit-touch-callout: none)，它是 iOS WebKit 的“指纹”。
- 别把
env(safe-area-inset-top)直接写进全局body { padding-top: ... }，否则安卓用户会看到多余空白 - 如果项目已用 CSS 自定义属性（如
--safe-area-top），记得在@supports块内重新赋值，外部声明不会自动注入 - 避免用
margin-top：它可能和子元素外边距折叠，且在scrollIntoView()行为中引发偏移
padding-top 加在哪个元素上才真正起作用
加在 body 上看似省事，但容易被后续 position: fixed 的头部覆盖或抵消。Banner 本身若也是固定定位，那它根本不受 body 的 padding 影响。
更可控的做法是明确作用于 Banner 容器自身：
- 给 Banner 的直接父容器（比如
.banner-wrapper）设padding-top: env(safe-area-inset-top) - 同时确保 Banner 内部文字用
box-sizing: border-box，避免 padding 撑高后溢出 - 如果 Banner 高度固定（如
height: 120px），可改用calc(120px + env(safe-area-inset-top))控制总高，防止横竖屏切换时突变
横竖屏切换、分屏多任务时的突变问题
env(safe-area-inset-top) 只在视口尺寸变化时更新，但 iOS 在横竖屏切换、分屏、快速切后台再切回等场景下，该值可能突变，而 CSS 不会自动重计算——Banner 文字可能瞬间被遮或突然多出大片空白。
如有动态适配需求，得监听 resize 并用 JS 触发一次强制重绘：
window.addEventListener('resize', () => {
document.body.classList.toggle('force-redraw', false);
void document.body.offsetWidth; // 强制 reflow
document.body.classList.toggle('force-redraw', true);
});
这个 trick 能让浏览器重新解析 env() 值，比单纯 class 切换更可靠。真机测试务必覆盖 iOS 16/17/18，模拟器有时返回错误的 env() 值。
真正容易被忽略的是：安全区变量不是“一次设置永久生效”，它依赖视口上下文；一旦页面进入分屏或多窗口模式，env(safe-area-inset-top) 可能从 44px 变成 0，而你的 Banner 若没做 fallback，就会直接贴顶。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
