为什么CSS单位vw和vh在移动端浏览器导航栏弹出时会失效？-css教程-PHP中文网

vw在导航栏弹出时“看起来失效”并非单位本身问题，而是它始终基于页面加载时固定的layout viewport宽度计算，不随地址栏或软键盘显隐动态更新；真正影响表现的是父容器约束、viewport meta缺失或max-width等盒模型限制。

为什么css单位vw和vh在移动端浏览器导航栏弹出时会失效？

vw 为什么在导航栏弹出时“看起来失效”

根本不是 vw 失效，而是它始终基于 layout viewport 宽度计算，而这个宽度在页面加载后就固定了。导航栏弹出/收起、软键盘唤起，都不会改变 layout viewport 的宽度值——所以 50vw 始终等于“初始 layout viewport 宽度 × 0.5”，哪怕用户已经把地址栏滑走了、屏幕实际更宽了。

真正的问题常出在父容器：比如父级设了 max-width: 375px 或 width: 375px，子元素写 width: 50vw 就会被截断或撑不开。这不是单位问题，是盒模型约束优先级更高。

vw 必须配合正确的 <meta name="viewport" content="width=device-width, initial-scale=1.0">，否则 layout viewport 默认是 980px（iOS Safari）或更大，1vw 就远大于预期
避免同时设置 maximum-scale 或 user-scalable=no，它们可能阻断 layout viewport 的正确初始化
用 clamp(14px, 3.75vw, 18px) 替代单纯 font-size: 3.75vw，防止小屏文字过小不可读

vh 在导航栏/软键盘场景下为何“不准”

vh 不是失效，是被浏览器锁死在页面加载瞬间的视口高度上。iOS Safari 加载时地址栏开着，1vh 按那个带地址栏的高度算；等用户一滚动收起地址栏，实际可视区域变高，但 100vh 的像素值没变——结果就是轮播图被截顶、弹层底部留白、position: fixed 按钮错位。

Android 更麻烦：软键盘弹出时 window.innerHeight 突然缩水，但 100vh 还是“原来那个数”，导致固定定位元素被顶到可视区外。

别依赖 window.resize 事件来修正 —— iOS 上对地址栏收起响应不全，对软键盘基本不触发
visualViewport API 才是关键：Chrome 61+/Safari 15.4+ 支持，能实时捕获地址栏、键盘导致的可视区域变化
兜底写法必须用 px 单位：calc(100 * var(--vh, 1px))，不能写 calc(var(--vh, 1vh) * 100) —— 1vh 是相对单位，无法参与 calc 数值运算

dvh 是什么？能不能直接替代 vh

dvh（dynamic viewport height）是标准解法，代表“当前实际可用的视口高度”，会随地址栏显隐、键盘弹出实时更新。它不是 polyfill，是 W3C 新增的原生单位。

page-agent 浏览器控制（CDP）

使用 page-agent CLI（CDP）控制浏览器；CLI只能通过 GitHub Release 的 .tgz 安装，npm 官方包暂未发布。

下载

支持情况很现实：iOS Safari 16.4+、Chrome Android/Desktop 109+、Firefox Android 117+（需开启 layout.css.dvh-vw.enabled）。但 iOS 15.x 及更早版本、Android Chrome 108- 都不认 dvh，直接忽略整条声明。

必须搭配回退方案：height: 100vh; height: 100dvh; —— 后者覆盖前者，旧浏览器自动降级
不要写 @supports (height: 100dvh) 做条件加载，旧环境连 @supports 都不支持或判断失准
dvh 不能和 vh 混合计算，比如 calc(100vh + 10dvh) 在不支持 dvh 的环境会整条失效

旧系统（iOS 8–8.3 / Android 4.4）怎么保底

这些系统里 vh 不是不准，是根本不可靠：100vh 只占可视区 50%、滚动时不更新、键盘弹出后不重算。这不是兼容性问题，是底层实现缺陷。

别试图修 vh，改用 rem + JS 动态锚定设备可用高度：以 window.innerHeight 为基准，设 html 的 font-size，让 1rem = window.innerHeight * 0.01，再写 height: 80rem 表示占屏 80%。