根本原因是 layout viewport 宽度错误导致 vw 基准失准，必须加正确 viewport meta 且确保构建工具配置与设计稿宽度一致，避免混用自动转换与手动 vw 值。
vw 计算基准错了，页面就必然放大
根本原因不是 vw 本身有问题，而是它基于的「布局视口（layout viewport）」宽度远大于设备真实 CSS 像素宽度。比如 iPhone 在没加 <meta name="viewport"> 时，默认 layout viewport 宽度是 980px，此时 1vw = 9.8px；而你按 375px 设计稿换算的 16px → 4.27vw，实际渲染出来却是 4.27 × 9.8 ≈ 41.8px——文字和容器直接被撑大一倍以上。
- 必须加
<meta name="viewport" content="width=device-width, initial-scale=1.0">，否则所有vw值都基于错误基准 - 不要加
maximum-scale=1.0或user-scalable=no，某些安卓 WebView 会因此跳过 layout viewport 重置逻辑 - 微信 X5 内核旧版本（如 v6.8.0 之前）存在 bug：即使写了正确
meta，首次加载仍按 980px 计算vw，需用window.dispatchEvent(new Event('resize'))强制触发一次重计算
设计稿宽度和 vw 换算不匹配也会放大
如果你的设计稿是 750px 宽，但 CSS 里写 font-size: 4.27vw（对应 32px），那这个值只在视口宽度恰好为 750px 时才准确。一旦设备视口是 375px，4.27vw = 16.01px 是对的；但如果 postcss-px-to-viewport 配置成了 viewportWidth: 375，而你又手动写了 100vw 当 375px 用，两套逻辑打架，结果就是字体忽大忽小、整体比例崩坏。
- 确认构建工具中
postcss-px-to-viewport的viewportWidth参数和设计稿宽度严格一致（常见为375或750） - 避免混用：不要一边用插件自动转
px → vw，一边手写xxvw值，尤其是html { font-size: ... }这类全局控制项 - 检查是否误将根元素
font-size设为13.333vw（750 设计稿下 100px 对应值），这在小屏上会因小数精度丢失导致累计偏差，视觉上像“突然放大”
PC 端误用 vw 导致无限拉伸
当项目原本只面向移动端（375px ~ 414px），却在 PC 上打开时，100vw 变成 1920px 甚至更大，所有用 vw 的元素都会同比例暴涨。这不是 bug，是预期行为——vw 就是按当前视口宽度算的。
- PC 兼容不能靠“禁用 vw”，而要加媒体查询兜底：
@media (min-width: 768px) { .text { font-size: 16px; } } - 若必须用 vw 控制字号，可用
clamp()限制范围：font-size: clamp(14px, 4.27vw, 20px); - 慎用
transform: scale()或zoom强制缩小整个页面——会破坏点击热区、表单聚焦、固定定位等行为
vmin/vmax 被误当成 vw 使用
有人看到 vmin 能防拉伸，就直接把所有 vw 替换成 vmin，结果发现按钮变小、文字糊了。因为 10vmin 在 iPhone 14 Pro Max（竖屏）下是 10% × 852px ≈ 85px，但在 iPad mini（竖屏）下是 10% × 768px = 76.8px，数值本就不等，且 vmin 锚定的是宽高中的较小值，对横屏设备尤其敏感。
立即学习“前端免费学习笔记（深入）”；
-
vmin和vmax是用来保比例的，不是vw的平替 - 需要等比缩放图标/头像时用
vmin；需要铺满屏幕但不溢出时用vmax；常规文字、间距、容器宽度仍优先用vw+ 正确viewport配置 - 注意
dvh（动态视口高度）在键盘弹出时更稳定，但vmin/vmax不受键盘影响，这点常被忽略
vw，而是它背后那个看不见的 layout viewport 是否被正确初始化——这个初始化失败，后面所有计算都是空中楼阁。 
