vw 能实现移动端自适应，但必须配合 <meta name="viewport" content="width=device-width, initial-scale=1.0">，否则因 layout viewport 错误导致计算偏差；换算公式为 vw = (px × 100) / 设计稿宽度，推荐用 Sass 函数自动计算；vw 是纯 CSS 刚性缩放方案，而 rem 更可控，适合需精细调节的场景。
vw 能直接实现移动端自适应，但必须配合正确的 viewport meta 设置，否则在 iOS Safari 或部分安卓 WebView 中会失效——这是最常被忽略的前提。
为什么 vw 在某些手机上不生效？
根本原因不是浏览器不支持 vw（Chrome 20+、Safari 6.1+、iOS Safari 6.1+ 都支持），而是布局视口（layout viewport）没对齐设备物理宽度。比如 iPhone X 默认 layout viewport 宽度是 980px，此时 1vw = 9.8px，远大于设计稿预期的 1vw ≈ 3.75px（按 375px 屏宽算）。
- 必须加
<meta name="viewport" content="width=device-width, initial-scale=1.0">，否则vw基于错误的 layout viewport 计算 - 避免同时设置
maximum-scale或user-scalable=no，它们可能干扰 layout viewport 的初始化 - 微信内置浏览器（X5 内核）早期版本有 bug：未触发 layout viewport 重置时，
vw仍按 980px 计算，需强制触发一次 resize 或用 JS 补偿
如何把设计稿 px 值准确转成 vw？
假设设计稿基准宽度是 750px（行业常见），目标设备屏幕宽度为 375px，那么 1px 对应的 vw 值是 100 / 750 = 0.1333vw。换算公式就是：vw = (px 值 × 100) / 设计稿宽度。
-
100px→(100 × 100) / 750 = 13.333...vw→ 保留两位小数写成13.33vw - 不要四舍五入到整数，
13vw和13.33vw在 375px 屏上相差约1.2px，文字或边框易出现模糊或错位 - 用 Sass/Less 自动计算比手算更可靠：
@function px2vw($px) { @return ($px / 750) * 100vw; }
vw 布局和 rem 布局的关键差异在哪？
vw 是纯 CSS 方案，不需要 JS 注入根字体大小，但它的缩放是“刚性”的——所有元素随视口等比缩放，包括字体、边框、阴影。而 rem 可控性更强，能单独控制字号缩放节奏（比如只放大文字，不放大 icon）。
立即学习“前端免费学习笔记（深入）”；
-
vw下font-size: 16px→font-size: 4.27vw（按 750px 设计稿），在 414px 宽屏上变成17.68px；而 rem 方案可设断点，让字体在 414px 以上停在18px不再增长 -
vw对图标、border、box-shadow 同样缩放，容易导致小屏上边框过细（1px变成0.27vw≈0.8px，渲染模糊），需要用min-width或媒体查询兜底 - iOS Safari 中，
vw在横屏切换时偶尔延迟更新，rem因依赖 JS 重设根字体，反而响应更及时
哪些场景下 vw 会出问题？
vw 天然不适合处理「高度敏感」或「内容驱动」的布局，比如全屏轮播、固定比例容器、文字行高需要稳定像素值的排版。
- 用
height: 100vh时，iOS Safari 地址栏收起/展开会改变vh值，导致内容跳动；100vw宽度不受影响，但高度类单位要慎用 - 想做「自适应正方形」，
width: 50vw; height: 50vw;可行，但若容器内有文字，line-height用1.5em比1.5vw更稳——后者在窄屏下可能导致行高过小，文字挤在一起 - 第三方组件（如地图 SDK、图表库）内部用固定 px 值定位，强行套
vw可能破坏其坐标系，优先查文档是否支持响应式配置
真正麻烦的不是怎么写 vw，而是判断它该不该用——当设计要求「所有元素严格等比缩放」且不涉及复杂交互时，vw 最省事；一旦需要精细控制某类元素的缩放节奏或兼容老 WebView，就得切回 rem + 媒体查询组合方案。
