结论：vw/vh 不能混用宽高来保持元素比例，因视口宽高比差异会导致变形；应单向使用或改用 vmin/vmax，且需用 dvh 应对键盘弹出问题，并通过 PostCSS 精准换算设计稿。
直接说结论：用 vw 和 vh 适配不同比例的屏幕，不能简单混用宽高单位，更不能指望它们“自动拉伸不变形”——它们只是按视口尺寸等比缩放，而手机屏幕宽高比差异大（比如 19.5:9 和 4:3），强行用 50vw 宽 + 50vh 高，盒子大概率会压扁或拉长。
为什么不能混用 vw 和 vh 设置同一个盒子的宽高
混用意味着你把宽度锚定在视口宽度、高度锚定在视口高度，但这两个值随设备变化完全不协同。例如：
- iPhone 14 Pro Max（896×2079 px）：100vw ≈ 414px，100vh ≈ 932px，宽高比约 1:2.25
- 旧款 iPad mini（768×1024 px）：100vw ≈ 768px，100vh ≈ 1024px，宽高比约 3:4
同一套 width: 80vw; height: 80vh; 在这两台设备上渲染出的矩形，实际宽高比完全不同。视觉上就是“一个胖一个瘦”，UI 元素严重失真。
常见错误现象：img 或 div 被拉伸变形、文字排版错位、按钮高度突兀、全屏轮播图裁剪不一致。
立即学习“前端免费学习笔记（深入）”；
真正安全的 vw/vh 使用场景
适合用 vw 和 vh 的地方，是那些「只依赖单向尺寸」或「本身不要求固定宽高比」的布局需求：
- 全屏背景图容器：用
height: 100vh;+background-size: cover;，高度撑满，图片自动裁剪适配 - 响应式字体大小：用
font-size: clamp(16px, 4vw, 24px);，字号随屏幕宽度平滑变化 - 横向滚动区域：用
width: max-content;+overflow-x: auto;，内部项用flex: 0 0 80vw;控制单个卡片宽度 - 垂直居中容器：用
height: 100vh;+display: flex;+align-items: center;，不关心内部子元素宽高比
注意：vmin 和 vmax 是更稳妥的选择。比如图标容器设为 width: 20vmin; height: 20vmin;，能保证在任意设备上都是正方形。
移动端键盘弹出时 vh 失效怎么办
这是最常被忽略的坑：iOS Safari 和部分安卓浏览器在软键盘弹出时，100vh 仍按“完整视口”计算，导致内容被遮挡或底部留白。这不是 bug，是规范行为——vh 基于 layout viewport，而键盘弹出会缩小 visual viewport。
解决方案分三步走：
- 优先用
100dvh替代100vh：height: 100dvh;动态响应键盘、地址栏收起等变化 - 降级兼容：用
@supports not (height: 100dvh)包裹 fallback 样式，比如回退到100vh+ JS 监听resize微调 - 避免给 body 或 html 设
height: 100vh，容易触发 iOS 的滚动异常；改用 wrapper div +min-height: 100dvh
实测发现，Chrome 120+、Safari 16.4+、Firefox 110+ 已支持 dvh，但微信内置浏览器（X5 内核）仍不支持，需 JS 补偿。
设计稿转 vw/vh 的换算陷阱
设计师给的 750px 宽稿子，不是直接除以 7.5 就得 10vw。真实换算必须基于设备独立像素（DIP），而非物理像素：
- iPhone 13（2532×1170）DPR=3，逻辑宽度 = 1170 / 3 = 390px → 1vw = 3.9px
- 同理，750px 设计稿中一个 75px 的按钮，在 390px 逻辑宽设备上应为
75 / 390 * 100 ≈ 19.23vw - 但如果你粗暴写成
10vw（对应 39px），实际只有原设计的 52%，明显偏小
所以别手算。推荐用 PostCSS 插件（如 postcss-pxtoviewport）配置 viewportWidth: 375，它会自动按设备逻辑宽度做归一化转换。否则，真机测试时你会发现所有尺寸都“差一点”。
