vw在纯移动端封闭场景才可靠，因它仅基于视口宽度、不感知dpr/横屏/系统字体缩放；推荐vw+rem组合：html设font-size:3.75vw，样式用rem；禁用body宽度限制和非必要缩放；border/图标/图片/行高慎用vw；安卓WebView软键盘会误触vw重算，需降级处理。
vw单位在移动端等比缩放中到底靠不靠谱
靠，但只在「纯移动端、无横屏、无动态字体调整」的封闭场景里才真正可靠。vw本质是视口宽度的1%，100vw = 屏幕宽度，所以用它设font-size或容器宽高，确实能随屏幕线性缩放。但它不感知设备像素比、不响应横竖屏切换、也不管用户是否开了系统级字体放大——这些都会让“等比”当场失效。
如何用vw+rem组合实现可控等比缩放
直接全用vw写字号或间距，很快会失控：小屏字太小看不清，大屏字炸开。更稳的做法是把vw只用在根字体上，再用rem承接业务样式。这样缩放有锚点，也方便后期微调。
- 在
<html>标签上设置font-size: 3.75vw（即以375px设计稿为基准，1rem = 10px） - 所有字号、内边距、外边距统一用
rem，比如font-size: 1.6rem对应16px - 避免对
html或body设width/max-width，否则vw会按这个宽度算，不是真实视口 - 加
viewportmeta：<meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=no">，禁掉双击缩放和手动缩放，不然vw值会跳变
哪些地方千万别用vw
不是所有尺寸都适合用vw驱动。它天生缺乏语义和上下文，硬套反而破坏体验。
-
border：用vw设边框粗细，小屏下可能缩成看不见的线，建议固定1px或用transform: scale()模拟 - 图标尺寸：SVG内联图标用
vw宽高会导致stroke-width失真，优先用em或固定px - 图片宽高：直接
width: 100vw会溢出滚动条，必须配合overflow-x: hidden或用max-width: 100% - 字体行高：
line-height用vw会导致行距随屏幕乱跳，应保持无单位数值（如1.5）或rem
安卓WebView和iOS Safari的vw行为差异
iOS Safari对vw支持干净，但老版安卓WebView（尤其4.4–6.0）在软键盘弹出时会把vw按「键盘顶起后的可视区域」重新计算，导致页面突然缩小。这不是bug，是它真把键盘区域当成了新视口。
立即学习“前端免费学习笔记（深入）”；
- 检测方式：监听
resize事件，打印document.documentElement.clientWidth和window.innerWidth，两者差值大且频繁变化，基本就是键盘干扰 - 临时解法：键盘弹起时，强制把
html的font-size切回固定值（如16px），收起后再切回来 - 长期建议：这类交互密集页，放弃纯
vw方案，改用媒体查询分段适配（@media (max-width: 375px)）更稳
真正难的不是怎么写那几行CSS，而是得随时记得：vw只是个数学换算，它不管用户正在干嘛、手机横没横、系统字体调没调——这些细节漏掉一个，等比就变成错比。
