直接写 vw 值易出错，因 100vw 恒等于当前视口宽度，与设计稿 750px 基准无关；正确做法是统一换算逻辑，用 $vw-base: 375px 封装 @mixin vw-layout 混合宏，支持参数化输入、媒体查询降级及 @supports fallback，避免混用 vw/rem、慎用 calc 和 border-vw。
为什么直接写 vw 值在移动端容易出错
设计稿给的是 750px 宽，你写 width: 50vw，结果在 iPhone SE（375px 屏）上元素宽了两倍——因为 100vw 永远等于当前设备视口宽度，和设计稿基准无关。真正要的是“设计稿里 100px 的元素，在任意屏幕下占同等视觉比例”，这需要统一换算逻辑，而不是手算。
用 @mixin vw-layout 封装视口单位布局逻辑
混合宏比函数更适合处理整套布局规则（比如同时控制 font-size、padding、max-width），且能自然注入媒体查询 fallback。不要只封装单个值转换，而是把“基准宽度 → 视口单位 → 降级方案”打包成一个可复用的布局单元。
- 定义基准变量：
$vw-base: 375px（推荐用 375，覆盖多数竖屏手机，避免设计稿 750px 下除以 750 导致数值过小难读） - 混合宏必须接收设计稿像素值作为参数，例如：
@mixin vw-layout($width, $height: null, $font-size: null) - 内部用
#{$width / $vw-base * 100}vw计算主值，但关键是要加@media (max-width: $vw-base)降级块，防止超小屏（如折叠屏半展开态）溢出 - 别在 mixin 里硬写
html { font-size: ... }——那是 JS 或 root rem 方案的事，@mixin vw-layout只管容器级尺寸
@mixin responsive-viewport 如何兼顾 fallback 和可维护性
纯 vw 在 iOS Safari 旧版本或某些安卓 WebView 中会跳变或失效，必须提供 px 或 rem fallback。但 fallback 不是简单叠一层 width: 100px; width: 26.666vw——那样会导致 CSSOM 计算冲突，尤其在动画中。
- 正确做法：用
@supports (width: 100vw)包裹vw规则，fallback 写在外面（优先级更低） - 混合宏里用
@if $fallback == true控制是否注入 fallback 块，避免每个调用都生成冗余 CSS - 慎用
calc()混合vw和px（如calc(100vw - 20px)），部分低端机型解析异常；如需减去固定边距，改用嵌套容器 +padding更稳妥 - 若项目已用
rem方案，不要在同一个组件里混用vw和rem布局逻辑，否则缩放行为不可预测
容易被忽略的兼容细节：DPR 和字体抗锯齿
vw 值本身不感知 DPR，但文字渲染会。你在 375px 屏上设 font-size: 4.266vw（≈16px），在 DPR=3 的 iPhone 14 Pro 上，实际渲染可能发虚——因为浏览器把 16px 字体按 48 物理像素渲染，而 subpixel 位置没对齐。
立即学习“前端免费学习笔记（深入）”；
- 解决方案：对文字类属性（
font-size、line-height）单独加text-rendering: optimizeLegibility，并在混合宏里用@if $is-text参数区分处理 - 避免用
vw控制 border 宽度，它不会随缩放变化；改用transform: scale()或媒体查询分段设置 - 测试真机时重点看横屏切换瞬间：某些 Android 系统会先触发
resize再重绘，导致vw值短暂错乱，这时 fallback 能救命
