<p>核心是让1rem对应设计稿1px，如750px设计稿设html font-size为calc(100vw / 750 * 100)，需注意浏览器最小字号限制、软键盘导致的vw塌缩、viewport配置及rem/vw混用时根字号统一。</p>
vw设置html font-size时怎么算基准值
核心是让1rem对应设计稿里的1px，比如750px设计稿习惯设根字号为100px，那就要让html{font-size:13.3333vw}（100 ÷ 750 × 100）。别硬背数字，用calc(100vw / 750 * 100)更安全，也方便后期改设计稿宽度。
注意浏览器对font-size有最小限制：Chrome最低11.32px，多数安卓和iOS强制≥12px。如果算出来12.5vw在小屏设备上低于12px，实际会被截断——得加@media兜底或改用JS动态校验。
- 设计稿640px →
font-size:15.625vw - 设计稿1080px →
font-size:9.25926vw - 真机测试时，横屏切换后检查
getComputedStyle(document.documentElement).fontSize是否跳变
哪些地方必须用rem，不能直接用vw
字体、内边距、外边距这些可随视口连续缩放的属性，用vw没问题；但涉及固定视觉节奏或需规避软键盘bug的场景，rem更稳。
iOS Safari唤出软键盘时，100vw会按“视觉视口”重算，导致html font-size骤降，所有vw单位跟着塌缩。输入框、弹层标题、按钮高度这类交互密集区域，建议统一用rem，靠根字号兜底。
立即学习“前端免费学习笔记（深入）”；
-
input的height、line-height用rem，避免键盘弹起后文字被切 - 圆角
border-radius、border-width用rem，vw在小数渲染时安卓有舍入误差 - 图标尺寸若来自雪碧图或字体图标，优先rem，否则vw缩放可能模糊或错位
混用vw和rem时如何避免单位逻辑冲突
不是“两个单位一起用就更弹性”，而是要确保它们共享同一缩放源头。常见错误是：用vw设html font-size，又在JS里另起一套动态计算rem基准——结果CSS里1rem = 16px，JS里却设成20px，整个UI比例崩掉。
关键判断点：全项目只保留一种根字号控制方式。要么纯CSS（font-size: 13.3333vw），要么纯JS（document.documentElement.style.fontSize = ...），别交叉。
- PostCSS插件如
postcss-pxtorem的rootValue必须和你实际生效的根字号一致 - 如果用了
calc()动态设置font-size，就别再写@media去覆盖它，否则媒体查询可能被忽略 - BEM类名里不要出现
--mobile或--pc这类尺寸修饰符，响应靠单位值本身，不靠类名切换
viewport meta没配对会导致vw/rem全部失效
这是最常被忽略的前提。没这行<meta name="viewport" content="width=device-width, initial-scale=1, maximum-scale=1, user-scalable=no">，所有vw/rem都基于980px默认视口计算，页面直接压缩变形。
尤其注意width=device-width不能被JS动态覆盖，某些SPA框架会在路由切换时重写meta，导致后续vw计算基准漂移。建议内联写死在<head>最顶部。
- 真机调试时，在Safari Web Inspector里看
window.innerWidth和document.documentElement.clientWidth是否接近——差太多说明viewport没生效 - 安卓WebView里
initial-scale=1.0有时被忽略，可加minimum-scale=1强化，但别加user-scalable=yes，否则破坏适配一致性
实际项目里，最易踩的坑不在单位本身，而在“以为设了vw就万事大吉”，忘了软键盘、横竖屏、系统字号放大这些真实交互场景对视口的扰动。留一手rem兜底，比强行全vw更可靠。
