混用vw和vh会导致元素变形，因二者锚定独立变化的视口宽高，设备宽高比差异使同一代码渲染出不同宽高比；应改用vmin/vmax控制等比缩放，并用dvh应对键盘弹出等动态变化。
直接说结论：用 vw 和 vh 实现“精准适配”不靠盲目替换 px，而靠理解它们的锚定点差异、设备宽高比影响，以及键盘/地址栏等动态行为对视口高度的干扰。混用 vw 和 vh 控制同一元素宽高，90% 会变形；写 100vh 做全屏容器，在 iOS 上大概率被键盘遮挡。
为什么 width: 50vw; height: 50vh; 会让元素拉伸或压扁
因为 vw 锚定视口宽度，vh 锚定视口高度，二者完全独立——iPhone 14 Pro Max 的宽高比约 1:2.25，iPad mini 是 3:4，同一套代码算出来的宽高比根本不同。
- 常见错误现象：
img被横向拉长、轮播图裁剪错位、按钮高度突兀、aspect-ratio失效 - 真正需要的是“比例一致”，不是“各自缩放”——该用
vmin或vmax替代 - 例如正方形头像容器：
width: 20vmin; height: 20vmin;，边长永远取vw和vh中较小那个的 20% - 若需 16:9 容器，优先写
aspect-ratio: 16/9; width: 90vmin;，让浏览器自动算高，别手动设height: 56.25vh
为什么 100vh 在手机上“不够高”甚至遮挡内容
因为 vh 基于 layout viewport（初始视口），而软键盘弹出、地址栏收起时，实际可视区域（visual viewport）变小了，100vh 却不变。
- 典型表现：底部按钮被键盘盖住、固定定位导航栏错位、滚动条意外出现
- 优先用
height: 100dvh;——它响应 keyboard、address bar 等所有动态变化 - 兼容 fallback 必须用
@supports not (height: 100dvh)包裹，比如降级为100vh+ JS 监听resize微调（注意防抖） - 别给
html或body设height: 100vh，iOS 容易触发滚动异常；改用 wrapper div +min-height: 100dvh - 微信 X5 内核（截至 2026 年 6 月）仍不支持
dvh，必须降级
字体和图片用 vw/vh 时怎么避免失控
直接写 font-size: 4vw 或 img { width: 90vw; height: 50vh; } 在超宽屏或小屏下极易崩溃——字体忽大忽小，图片溢出或塌陷。
- 字体必须用
clamp()：例如font-size: clamp(14px, 2.5vw + 0.5rem, 18px);，三值分别对应最小、理想、最大字号 - 图片宽高比不匹配时，
height: auto比硬设vh更安全；若需等比缩放，用aspect-ratio+width: 80vmin - 父容器设了
max-width会覆盖vw效果，检查是否意外截断了计算结果 - 设计稿换算推荐用 PostCSS 插件
postcss-px-to-viewport，而非手写calc()，减少误差和维护成本
最常被忽略的点是：vmin/vmax 和 dvh 都不能解决父容器盒模型或 overflow 导致的渲染偏差；实际项目里，先确保 viewport meta 标签正确，再逐层验证容器尺寸是否被意外约束。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
