100vh在移动端出错是因为浏览器将其锁定为页面加载瞬间的视口高度，iOS Safari地址栏收起或Android软键盘弹出时实际可视区域变化但100vh不变；需用JS动态计算--vh为px单位并配合visualViewport监听。
为什么直接用 100vh 在移动端会出错
不是你 CSS 写错了，而是浏览器把 100vh 锁死在页面加载瞬间的视口高度上。iOS Safari 加载时地址栏还开着，1vh 就按那个带地址栏的高度算；等用户一滚动，地址栏收起、可视区域变高，100vh 的像素值却没变——结果轮播图被截顶、弹层底下留白、固定按钮错位。Android Chrome 同样存在，尤其在软键盘弹出时，window.innerHeight 突然缩水，但 100vh 还是“原来那个数”。
--vh 变量必须写成 px 单位，不能写 vh
很多人卡在这步：calc(var(--vh, 1vh) * 100) 看似合理，实际无效。因为 1vh 是相对单位，无法参与 calc() 中的数值乘法运算，浏览器会直接忽略整条声明。
正确做法是让 JS 写入一个带 px 单位的值，CSS 里用它当“1% 基准”：
- JS 中：
document.documentElement.style.setProperty('--vh', `${window.innerHeight * 0.01}px`) - CSS 中：
height: calc(100 * var(--vh, 1px)) - 兜底值必须是
1px（或明确像素值），不能是1vh或空字符串
监听 resize 不够，还得处理 visualViewport 和键盘场景
window.resize 在 iOS 上对地址栏收起响应不全，对软键盘弹出基本不触发。真正能捕获这些变化的是 visualViewport API（Chrome 61+/Safari 15.4+）。
立即学习“前端免费学习笔记（深入）”；
推荐组合监听：
- 优先用
window.visualViewport?.addEventListener('resize', setVh) - 降级 fallback 到
window.addEventListener('resize', setVh) - 横竖屏切换加
window.addEventListener('orientationchange', setVh)（iOS 对resize有时延迟） - 首次执行必须在 DOM ready 后立即调用，否则首屏渲染仍用错误值
注意：某些安卓 WebView 或华为 EMUI 系统中 visualViewport.height 可能返回异常值，需校验 if (v.height > 0 && v.height 。
别在绝对定位容器里依赖 --vh 算高度
如果元素是 position: absolute，而它的父容器没有显式高度（比如没设 height: 100%），那么 height: calc(100 * var(--vh)) 实际上不会生效——因为绝对定位元素的百分比高度依赖包含块高度，而非视口。
更可靠的做法是绕过高度计算：
- 用
top: 0; bottom: 0;直接撑满父容器（前提是父容器有定位上下文） - 若父容器本身也靠
--vh驱动，得确保它先完成初始化，否则子元素读到的是初始1px值 - 服务端渲染（SSR）页面首次 hydration 前，
--vh是未定义的，必须在客户端 JS 执行后重设，否则布局闪动
真正难的从来不是写几行 JS，而是覆盖所有边界：键盘弹出瞬间的冻结、WebView 里事件缺失、老 iOS 机型连 visualViewport 都不支持——这些细节堆起来，才决定用户看到的是“刚好填满”，还是“忽长忽短”。
