100vh/100vw无法实现全机型无缝填满，因iOS Safari等WebView中视口动态变化导致失准，须配合env()降级链或visualViewport事件JS补偿。
纯用 100vh / 100vw 无法实现“全机型无缝填满”——它在 iOS Safari、微信 WebView、部分安卓 WebView 中会因视口动态变化而失准，必须搭配 fallback 或 JS 补偿。
为什么 100vh 在 iOS Safari 里经常“差一截”或“多一点”
iOS Safari 的 100vh 基于页面加载时的布局视口（layout viewport），而地址栏滚动时收起/展开会改变视觉视口（visual viewport）高度，100vh 却不更新。结果就是：下拉刷新后底部露白，或滚动到底部时内容被截断。
- 这不是 bug，是规范行为——
vh定义为“初始布局视口高度的 100%” - 微信内置浏览器、QQ 浏览器、部分三星/华为系统 WebView 有同样表现
- 真机调试时最容易暴露：模拟器常“假装稳定”，但真机一滚就出问题
- 仅靠
height: 100vh做登录页、轮播封面、全屏弹窗，上线后大概率被反馈“底部黑边”或“文字看不见”
现代 CSS 方案：优先用 env(height) + fallback 链
iOS 11+ 支持 env(height)，它响应视觉视口实时变化，比 100vh 更准；但必须提供降级路径，否则旧版 Safari 或安卓 WebView 会直接失效。
- 写法必须按顺序声明，CSS 会取第一个有效值：
height: 100vh;<br>height: -webkit-fill-available;<br>height: env(height);
-
-webkit-fill-available在 Safari 中等效于“当前可用视口高度”，兼容性比env()更广 - 别漏掉
env(safe-area-inset-bottom)：刘海屏/全面屏需留出底部安全区，否则按钮被 Home Indicator 挡住 - 若元素需撑满且带固定 header，用
calc(env(height) - 64px)比calc(100vh - 64px)更稳
必须用 JS 的场景：要求 100% 对齐视觉视口
当设计稿明确要求“绝对贴边、零留白、无滚动条”，比如沉浸式引导页、AR 启动页、横屏游戏容器，纯 CSS 的 env() 仍可能在地址栏动画过程中短暂滞后。
立即学习“前端免费学习笔记（深入）”；
- 监听
visualviewport事件比resize更精准：window.visualViewport?.addEventListener('resize', () => {<br> const vh = window.visualViewport.height * 0.01;<br> document.documentElement.style.setProperty('--vh', `${vh}px`);<br>}); - 务必节流：直接在事件里改 CSS 变量会高频触发重排，推荐用
requestAnimationFrame批处理 - 首屏闪动不可避免：JS 执行前已按
100vh渲染，可加opacity: 0+transition缓解 - 不要在 SSR 页面里依赖该方案——
visualViewport服务端不存在，需客户端 hydrate 后再激活
100vw 的坑比 100vh 少，但仍有两个关键点
100vw 虽不随滚动跳变，但默认包含滚动条宽度（约 17px），容易导致水平溢出和滚动条闪现。
- 必做
body { margin: 0; }，否则浏览器默认8px外边距会让100vw元素右侧多出空白 - 如果父容器有
padding，子元素设width: 100vw会突破父级边界——此时应改用width: 100%并确保父级width: 100% - 避免用
calc(100vw - 17px)扣滚动条：不同设备、不同系统、暗色模式下滚动条宽度不同，不可靠 - 更稳妥的做法是给 body 或 wrapper 加
overflow-x: hidden，而不是硬调宽度
真正“无缝”的关键不在单位本身，而在你是否预判了视口在真实设备上的所有变化形态——地址栏、键盘、安全区、缩放、横竖屏切换，这些都会让“一屏高”变成一个动态值。CSS 提供了 env() 这样的现代能力，但它不是银弹；fallback 链和 JS 补偿不是退而求其次，而是面向真实设备的必要设计。
