env(safe-area-inset-bottom) 仅在 iOS Safari 和 WebKit 浏览器中可靠，Android 原生 Chrome 未实现该特性，各厂商手势条高度不统一且无标准化 CSS 接口，需用 JS 结合 UA 检测与尺寸差值估算并动态注入 CSS 变量。
env() 不能跨厂商适配底部手势条，它只在 iOS Safari 和 WebKit 内核浏览器中可靠生效；Android 端基本无效，别指望靠它解决三星、华为或 Pixel 的手势区域问题。
为什么 env(safe-area-inset-bottom) 在 Android 上多数时候没用
Android 原生 Chrome（非 WebView）至今未实现 env(safe-area-inset-bottom)，包括 Pixel、One UI 4.0+、MIUI 和 HarmonyOS 的系统浏览器。部分 Samsung WebView 或 One UI 3.1+ 的内嵌 WebView 可能返回值，但不可依赖——实测中常为 0px 或直接忽略整条声明。
- 打开 Chrome DevTools → 切换到 Android 设备模拟 → 检查 computed styles，搜
env(safe-area-inset-bottom)，大概率是空或auto - 真机调试时，用 Safari 远程调试 iOS 设备能看到真实值（如竖屏
34px），但 Android 没对应调试通道 - Android 手势条高度不统一：三星是 80dp，华为/小米约 64dp，Pixel 是 72dp，且随系统版本浮动，CSS 环境变量根本没标准化接口暴露这些
iOS 端必须满足的三个硬性条件
就算只做 iOS 适配，env(safe-area-inset-bottom) 也绝不是写上就生效。漏掉任意一条，值就是 0px 或被跳过：
-
<meta name="viewport" content="width=device-width, initial-scale=1.0, viewport-fit=cover">必须存在，且不能被 JS 动态覆盖（比如某些 UI 库会重写<meta>） - 必须用
@supports (padding-bottom: env(safe-area-inset-bottom))包裹规则，@supports (env(safe-area-inset-bottom))是非法语法，整块 CSS 会被丢弃 - fallback 值必须带单位，
padding-bottom: env(safe-area-inset-bottom, 0px)合法，env(safe-area-inset-bottom, 0)无效
fixed 底部按钮该加在哪？别加错位置
对 position: fixed 元素，padding-bottom 完全不起作用——它脱离文档流，父容器的 padding 不会影响它。真正有效的只有两种写法：
立即学习“前端免费学习笔记（深入）”；
- 用
bottom：bottom: env(safe-area-inset-bottom, 34px);（注意单位不能省） - 用
inset（更推荐）：inset: auto 0 env(safe-area-inset-bottom, 34px) 0;，语义更清晰，兼容性与bottom一致 - 绝对不要写
margin-bottom: env(safe-area-inset-bottom)—— 在 flex 容器里会导致子项被挤出视口，尤其当内容高度不足时
Android 端只能靠 JS 降级 + UA 特征检测
目前没有纯 CSS 方案能稳定获取 Android 手势条高度。可行路径是：
- 先检查
env(safe-area-inset-bottom)是否有效（用@supports），有效则走 iOS 路径 - 否则判断 UA 字符串是否含
Android+Chrome，再结合window.innerHeight与window.screen.height差值粗估（误差 ±10px） - 更稳妥的是监听
resize事件，对比document.documentElement.clientHeight与window.innerHeight，软键盘弹出时差值突变，手势条则相对稳定 - 最终把计算出的高度存为 CSS 变量：
document.documentElement.style.setProperty('--android-safe-bottom', `${height}px`)，再在 CSS 中用calc(34px + var(--android-safe-bottom, 0px))
真正容易被忽略的是：iOS 的 env() 值会在 Safari 地址栏自动隐藏/显示时动态变化，而 Android 的 JS 估算值是一次性的——如果用户横屏再切回竖屏，得重新触发检测，否则底部留白会错位。
