在 iPad 版 Chrome（iOS/iPadOS）中，100vh 常因浏览器对视口高度的错误计算而失效，导致页面实际高度远超屏幕、出现多余滚动空间；本文提供兼容 Safari 与 Chrome 的稳健 CSS 修复方案。
在 ipad 版 chrome（ios/ipados）中，`100vh` 常因浏览器对视口高度的错误计算而失效，导致页面实际高度远超屏幕、出现多余滚动空间；本文提供兼容 safari 与 chrome 的稳健 css 修复方案。
在 iPadOS 上使用 Chrome 浏览器时，开发者常遇到一个典型布局问题：即使为 <html> 和 <body> 设置了 height: 100vh，页面仍会渲染出远超可视区域的高度（如表现类似 200vh），右侧出现垂直滚动条，且滚动到底部为空白区域。该问题仅出现在 iPad 版 Chrome（基于 WebKit 但行为有偏差），而 Safari 表现正常——根本原因在于 Chrome for iOS 对 vh 单位的解析未正确考虑地址栏/工具栏的动态隐藏状态，且 -webkit-fill-available 等实验性值在混合使用时易引发高度叠加。
✅ 推荐解决方案（按优先级排序）
1. 移除干扰属性，回归标准 100vh
最简洁可靠的修复是移除所有 -webkit-fill-available 相关声明，仅保留语义清晰的 100vh：
html {
height: 100vh;
}
body {
margin: 0;
height: 100vh;
}同时确保 HTML 结构中无默认边距干扰（如 <body> 默认 margin）：
<body style="margin: 0;"> <div style="background-color: green; height: 100%; width: 100%;">This is a div</div> </body>
⚠️ 注意：<div> 内部使用 height: 100% 时，其父元素（即 body）必须具有明确高度（如 100vh），否则百分比高度将失效。
2. 备选方案：统一使用 100% 高度链
若 100vh 在特定 Chrome 版本仍有波动，可改用 100% 高度继承链（需确保所有祖先元素高度明确）：
html, body {
height: 100%;
margin: 0;
}此时子元素 height: 100% 才能可靠生效。
3. 精准定位 Chrome（iOS）的媒体查询（慎用）
仅当上述方法无效且需差异化处理时，可借助 Chrome 特有的 -webkit-min-device-pixel-ratio 特征进行条件样式注入：
/* 仅作用于 WebKit 内核且支持设备像素比的环境（覆盖 Chrome iOS） */
@media screen and (-webkit-min-device-pixel-ratio: 0) {
html, body {
height: 100vh;
}
}但需注意：此规则无法精确区分 Safari 与 Chrome（二者均满足条件），因此更推荐优先采用方案 1。
? 关键总结
- 根本原因：Chrome for iOS 错误地将地址栏展开/收起状态纳入 vh 计算，且 -webkit-fill-available 与 100vh 混用会导致高度累加；
- 最佳实践：避免在 iOS 环境中混用 vh 与 -webkit-fill-available；始终重置 body { margin: 0 }；
- 验证方式：在 iPad Chrome 中打开开发者工具（通过 macOS Safari 远程调试），检查 html 和 body 的 computed height 是否严格等于 window.innerHeight。
遵循以上任一方案，即可彻底消除异常滚动条，实现真正全屏、无冗余空间的响应式布局。
