必须添加viewport-fit=cover，否则env()函数在iOS和部分Android WebView中返回0；需配合initial-scale=1.0使用，并用@supports检测兼容性，fallback值应基于非全面屏设备实测。
viewport-fit=cover 必须加，否则 env() 拿不到安全区值
不加 viewport-fit=cover，env(safe-area-inset-top) 这类函数在 iOS 和部分 Android WebView 中会返回 0，哪怕设备有刘海或圆角。这不是 bug，是规范行为：浏览器默认只把内容渲染在安全区内，只有显式声明「我要撑满」，才暴露安全区边距变量。
正确写法是：
<meta name="viewport" content="width=device-width, initial-scale=1.0, viewport-fit=cover">
注意：initial-scale=1.0 不能省——iOS Safari 在某些系统版本里，缺了它会导致页面意外缩放，让 env() 计算错乱；user-scalable=no 可选，但若保留，需同步做无障碍测试。
用 env() 给关键区域留白，不是全屏铺满就完事
加了 viewport-fit=cover 后，页面确实能“顶到屏幕边缘”，但顶部导航、底部按钮很可能被刘海或 Home Indicator 挡住。这时候得靠 env() 主动避让：
立即学习“前端免费学习笔记（深入）”；
-
env(safe-area-inset-top)用于给<header></header>或固定定位的顶部栏加padding-top -
env(safe-area-inset-bottom)用于给<footer></footer>或 tabbar 加padding-bottom -
env(safe-area-inset-left)和env(safe-area-inset-right)很少用，除非你做了侧滑菜单且内容贴边
示例（带 fallback）：
.header {<br> padding-top: env(safe-area-inset-top, 20px);<br>}<br>.tabbar {<br> padding-bottom: env(safe-area-inset-bottom, 10px);<br>}
fallback 值（如 20px）不是随便写的：它应等于你在非全面屏设备（如 iPhone 8）上测得的最小可用安全间距，确保降级时 UI 不挤压。
rem/vw 方案和 env() 不冲突，但别混着算逻辑
很多项目已用 rem 做整体缩放（比如根据 375px 设计稿动态设 html.font-size），这和 env() 是正交的：前者管比例，后者管边界。
容易踩的坑：
- 在
rem计算中直接套用env()值（如calc(1rem + env(safe-area-inset-top))）——env()返回的是 px 值，而rem是相对单位，混用会导致计算失效 - 用
vw做宽度适配时，误以为它自动规避安全区——vw是视口宽度单位，不感知物理遮挡，该溢出还是溢出 - 在 flex 容器里对子项用
env()做 margin，却忘了父容器没设overflow: hidden，导致滚动条异常出现
iOS 和 Android 行为差异必须手动兜底
env() 在 iOS Safari 上支持完整、稳定；但在 Android，仅较新 WebView（Chrome 90+、Android 12+）才支持，旧版直接忽略 env() 并使用 fallback 值。
所以真实项目里要：
- 用
@supports (padding-top: env(safe-area-inset-top))包裹核心安全区样式，避免旧 Android 解析失败 - 对底部操作区，额外加一层 JS 检测：读取
window.visualViewport?.height与window.screen.height差值，粗略判断是否弹出了软键盘或系统栏 - 不要依赖
safe-area-inset-bottom判断 Home Indicator 是否可见——有些 Android 厂商（如华为 EMUI）把它设为0即使存在小黑条
最稳妥的做法是：把 env() 当作「增强体验」而非「功能必需」，所有关键交互控件本身就得有足够点击热区（至少 44×44px），不能只靠 padding 推出来。
