env(safe-area-inset-bottom) 在 ios 11+ safari/wkwebview 中返回精确像素值（如 iphone 15 pro max 为34px），需配合 viewport-fit=cover 才生效，推荐用双声明兜底并慎选 padding/margin 应用方式。
env(safe-area-inset-bottom) 在 iOS 11+ 中的实际取值逻辑
这个 CSS 环境变量只在有物理安全区域（如 iPhone X 及后续带刘海/小黑条的机型）的 Safari 和 WKWebView 中返回非零值，其他环境（Chrome on iOS、Android、桌面端）默认返回 0px。它不是“底部是否有缺口”的布尔开关，而是精确的像素值——比如 iPhone 15 Pro Max 底部小黑条高度是 34px，env(safe-area-inset-bottom) 就返回 34px。
关键点：它不触发重排，也不随横竖屏自动更新（iOS 15 之前存在横屏后值未刷新的问题），所以不能依赖它做动态布局切换，只适合静态留白或配合 viewport-fit=cover 使用。
必须配合 viewport meta 才生效
如果 <meta name="viewport" content="width=device-width, initial-scale=1"> 没加 viewport-fit=cover，iOS 会自动把页面内容“缩进”到安全区域内，此时 env(safe-area-inset-bottom) 虽然可读，但你根本用不上——因为底部已经被系统强制留白了。
正确写法是：
<meta name="viewport" content="width=device-width, initial-scale=1, viewport-fit=cover">
这样页面才真正“撑满”屏幕，把控制权交还给 CSS，你才能用 env() 主动适配。
- 漏掉
viewport-fit=cover→env(safe-area-inset-bottom)值存在但无意义 - 写了
viewport-fit=cover但没用env()→ 页面底部可能被小黑条遮挡 - 两者都到位，才是完整链路
padding-bottom 和 margin-bottom 的选择陷阱
多数人第一反应是给 body 或页脚容器加 padding-bottom: env(safe-area-inset-bottom)，这在纯内容页可行；但遇到固定定位的 tabbar、悬浮按钮，padding 会把内容整体上推，破坏视觉锚点。
更稳妥的做法是用 margin-bottom 或 height + calc()：
footer {<br> margin-bottom: env(safe-area-inset-bottom);<br>}
或者针对全屏滚动容器：
.scroll-container {<br> height: calc(100vh - env(safe-area-inset-bottom));<br>}
注意：env() 不能直接用于 min-height 或 max-height 的 calc 表达式中（部分旧版 Safari 会失效），优先用 height 或 padding。
兜底 fallback 必须写，且不能只靠 initial value
CSS 中 env(safe-area-inset-bottom, 0px) 的第二个参数只是语法 fallback，不代表浏览器兼容性兜底——Android、桌面端、老 iOS 都不支持 env()，会直接忽略整条声明。
正确做法是双声明 + 层叠覆盖：
padding-bottom: 0px;<br>padding-bottom: env(safe-area-inset-bottom);
现代浏览器会覆盖前一行，旧浏览器只认第一行。别用 @supports (env(safe-area-inset-bottom)) 包裹——它在不支持的环境里压根不执行，反而导致无 fallback。
另外，微信内置浏览器（iOS 版）从 8.0.30 开始支持 env()，但早期版本仍需检测 UA 并走 JS 注入 class 的降级路径，这点常被忽略。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
