vw/vh在移动端更受欢迎,核心原因是不依赖js动态设置根字体且不受系统字体缩放干扰;它基于视口原生计算,css解析即生效,避免白屏、错乱与布局抖动,ios/android主流版本已全面支持。

vw/vh 在移动端更受欢迎,核心原因就一条:它不依赖 JavaScript 动态设置根字体,也不受系统字体缩放干扰 —— 适配逻辑更干净、更稳定。
vw/vh 不需要 JS 就能响应式缩放
rem 布局必须在 插入一段 JS(比如淘宝的 flexible.js 或自写逻辑),监听 window.onresize 或 DOMContentLoaded,再动态改 document.documentElement.style.fontSize。而 vw/vh 直接基于视口计算,浏览器原生支持,CSS 解析完就生效。
- 常见错误现象:
rem页面在 iOS 微信中白屏或字体突变,往往是因为 JS 加载失败或执行时机不对 - 使用场景:ShopXO 的轮播图、商品列表页(
public/static/index/default/css/style.css)全用vw,省去 JS 注入和事件监听开销 - 性能影响:减少 JS 执行、避免强制同步布局(
layout thrashing),首屏渲染更快
vw/vh 对系统字体缩放免疫
Android/iOS 系统设置里调大「辅助字体」后,rem 布局会整体被拉伸错乱 —— 因为根元素 font-size 被系统强制放大,所有 rem 值跟着失真。而 vw 始终以物理视口宽度为基准(1vw = 1% of window.innerWidth),完全不受系统级缩放影响。
- 容易踩的坑:用
rem做按钮尺寸时,用户开启「大字体模式」后,按钮可能撑出容器、点击热区偏移 - 参数差异:
100vw包含滚动条宽度(属于 viewport 范围),但100%不包含;实际做全宽容器时,width: 100vw可能导致横向滚动,需加overflow-x: hidden或用width: 100%替代 - 兼容性底线:iOS 8+、Android 4.4+ 全面支持,2026 年已无兼容顾虑
vw/vh 与 rem 混用可兼顾精度与兼容性
纯 vw 写字体大小时,小屏下文字可能过小(如 font-size: 4vw 在 320px 屏上仅 12.8px),此时用 clamp() 或 rem 做兜底更稳妥。ShopXO 后台管理页(public/static/admin/default/css/common.css)就采用 rem 主控 + vw 辅助的方式。
- 实操建议:用 Sass 函数封装转换,例如:
@function vw($px) { @return ($px / 750) * 100vw; }视觉稿按 750px 宽设计,div { width: vw(120); font-size: clamp(14px, 4vw, 18px); } - 为什么这样做:避免纯
vw在极端小屏下不可读,也避免纯rem被系统字体干扰;clamp()提供最小/最大限制,比媒体查询更轻量 - 容易忽略的点:
vh在 iOS Safari 中有安全区域问题(如刘海屏底部被截),涉及全高布局时优先用env(safe-area-inset-bottom)补齐,而不是硬写100vh
真正难的不是选 vw 还是 rem,而是意识到:vw/vh 的“零 JS”优势只在你放弃用它模拟 px 逻辑时才成立 —— 一旦开始写 html { font-size: 26.6666666vw; } 这类 hack,反而把问题又绕回去了。
前端入门到VUE实战笔记:立即使用
在学习笔记中,你将探索 前端 的入门与实战技巧!











