vw可大幅简化rem的JS依赖，因其是浏览器原生响应视口的CSS单位，无需监听事件或处理执行时机；但需用媒体查询兜底防小屏字号过小，并注意border、padding等属性在vw下的亚像素渲染问题。
不能完全替代，但可以大幅简化 rem 的 JS 依赖逻辑；关键不是“替代”，而是“解耦根字号计算”。
为什么直接用 vw 设置 font-size 就能去掉 JS？
rem 布局卡在「动态改 html 的 font-size」这一步，传统方案靠 JS 监听 resize 或 DOMContentLoaded 计算并写入。而 vw 是纯 CSS 视口单位，浏览器原生实时响应宽度变化——只要设计稿基准宽度确定（如 750px），就能用 calc() 或预处理器函数直接推导出根字号：
-
html { font-size: calc(100vw / 750 * 100); }→ 等效于「iPhone 6 下 1rem = 100px」 - 无需监听页面加载、设备旋转、键盘弹出等事件，无 JS 执行时机问题
- 避免了 flexible.js 类库在 iOS Safari 中因
document.documentElement.clientWidth取值不准导致的缩放抖动
vw 给 font-size 赋值时，小屏上文字过小怎么办？
iOS 默认强制最小字号为 12px，font-size: 3.2vw 在 320px 屏上会变成 10.24px，最终被浏览器拉高到 12px，破坏比例。这不是 bug，是渲染策略：
- 不能依赖
min-font-size（仅 Safari 支持且兼容性差） - 必须用媒体查询兜底：
@media (max-width: 320px) { html { font-size: 12px; } } - 更稳妥的做法是设区间：比如 320–414px 用固定值，414px 以上才启用
vw动态计算 - 字体本身也建议用
clamp()替代单vw：font-size: clamp(14px, 4vw, 18px);
为什么 border: 1px 和 padding 在 vw 下容易糊或消失？
vw 对所有属性一视同仁：1px 边框在 375px 屏上变成 1px × (100 / 750) × 100 = 13.33vw → 实际约 0.89px，亚像素渲染导致模糊甚至不可见：
立即学习“前端免费学习笔记（深入）”；
- 边框建议统一用
border: 0.0133vw solid #000（按 750px 设计稿换算），但不如直接用1px+transform: scaleY(0.5)模拟物理像素线 - 内边距/外边距混用
vw和px会导致嵌套容器错位，尤其当父容器用了vw宽度而子元素用pxpadding 时 - 图标、分割线等对精度敏感的元素，应优先用 SVG 或伪元素 +
background-image，而非依赖vw缩放
横屏切换或键盘弹出时，vw 值为何延迟更新？
iOS Safari 在 layout viewport 重置过程中存在微小延迟（约 50–100ms），vw 值不会立刻重算，造成输入框附近元素短暂跳动。这不是代码问题，是 WebKit 渲染管线行为：
- rem 方案反而更稳——JS 重设根字号通常发生在 resize 事件后，有明确执行时机
- 若页面大量使用
vh控制高度（如全屏弹窗），键盘弹出会压缩可用视口高度，vh值突变，此时需监听resize用 JS 补偿（例如临时切回px高度） - 微信 X5 内核旧版本曾彻底不触发 layout viewport 重置，需加
window.dispatchEvent(new Event('resize'))强制刷新
真正难处理的从来不是换算公式，而是那些「看起来应该自动适配，却因浏览器底层机制而失效」的边界场景：iOS 字号下限、Android WebView 的 layout viewport 初始化时机、X5 内核对 vmin/vmax 的解析偏差……这些没法靠一个 vw 声明解决，得靠组合策略和实测兜底。
