根本原因是iPad版Chrome（v116+）将100vh与-webkit-fill-available视为两个独立可叠加的高度，导致总高度超出视口；Safari则自动协调二者。
为什么 100vh 在 iPad Chrome 中会超出视口高度
根本原因不是 vh 计算错了，而是 iPad 版 Chrome（v116+）把 100vh 和 -webkit-fill-available 当成两个独立、可叠加的“可用高度”来处理。Safari 则会自动协调二者，而 Chrome for iOS 不会。
典型触发场景是同时写了这两行：
html { height: -webkit-fill-available; }body { min-height: -webkit-fill-available; }
此时浏览器先按地址栏隐藏状态算出 100vh（比如 1024px），再额外加上 -webkit-fill-available 所代表的“含地址栏区域”（比如又 +80px），结果容器总高度远超屏幕可见区域，出现不可控滚动条。
用 -webkit-fill-available 替代 100vh 的实际限制
它确实能填满「当前可用显示区域」，但只在 WebKit 内核浏览器中生效（Safari / iOS Chrome），且行为不统一：
- 在 Safari 中，
height: -webkit-fill-available会动态响应地址栏收起/展开，表现稳定 - 在 iPad Chrome 中，它可能和
100vh或min-height冲突，尤其当父级已设height: 100%时，子元素设-webkit-fill-available反而被忽略 -
-webkit-fill-available会覆盖同属性的其他值，例如：height: 90vh; height: -webkit-fill-available;→ 后者生效，前者完全无效 - 它不支持 IE、Firefox、Android Chrome，必须加回退：如
height: 100vh; height: -webkit-fill-available;
更稳妥的方案：用 JS 动态计算 --vh
绕过浏览器对 vh 的静态解析缺陷，直接用 window.innerHeight 获取实时可视高度：
// 在页面加载和 resize 时更新
function setVh() {
const vh = window.innerHeight * 0.01;
document.documentElement.style.setProperty('--vh', `${vh}px`);
}
setVh();
window.addEventListener('resize', setVh);
然后在 CSS 中使用：
.full-height { height: calc(var(--vh, 1vh) * 100); }-
var(--vh, 1vh)是关键：现代浏览器用动态--vh，老浏览器 fallback 到静态1vh - 注意：iOS Safari 的
resize事件在地址栏切换时不一定触发，需配合orientationchange或短延时重算
容易被忽略的兼容细节
很多人以为加了 -webkit-fill-available 就一劳永逸，但实际落地时有三个隐性坑：
-
min-height: -webkit-fill-available在 flex 容器子项中可能失效，改用flex: 1更可靠 - 当页面存在
position: fixed元素时，-webkit-fill-available的“可用区域”仍包含被 fixed 元素遮挡的部分，视觉上仍可能溢出 - iOS 17+ 开始，
-webkit-fill-available对width的支持变得更不稳定，横向布局慎用
真正要稳，就得接受一个事实：移动端全高没有纯 CSS 的银弹，--vh + resize 监听仍是目前最可控的路径。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
