移动端布局推荐用css vw 代替 rem，核心原因是 vw 能实现基于视口宽度的绝对响应式，无需依赖 javascript 动态计算根字体大小，从而彻底消除页面加载时的布局闪烁（fouc）并简化适配逻辑。使用 vw 时，只需将设计稿尺寸除以 100 即可直接作为 css 单位，例如 750px 的设计稿中 100px 的宽度可直接写为 13.333vw，这种线性缩放在任何屏幕比例下都能保持元素间的相对位置不变。
rem 方案在 JS 初始化阶段存在哪些性能与稳定性风险？
rem 方案的风险主要源于其必须通过 JavaScript 监听 resize 事件来动态修改 document.documentElement.style.fontSize。这一过程不仅增加了主线程的计算负担，还极易因脚本加载延迟导致用户在 JS 执行前看到错误的默认字体大小，引发严重的布局抖动。此外，不同设备对 resize 事件的触发频率差异巨大，可能导致动画卡顿或内存泄漏。
const setRem = () => {
const width = document.documentElement.clientWidth;
// 假设设计稿为 750px，基准字体为 100px
const fontSize = (width / 750) * 100;
document.documentElement.style.fontSize = `${fontSize}px`;
};
window.addEventListener('resize', setRem);
setRem();上述代码展示了典型的 rem 初始化逻辑。当用户打开页面时，浏览器必须先解析 HTML 和 CSS，此时 fontSize 可能仍为默认的 16px。随后 JS 执行 setRem，强制重排（Reflow）整个文档树以应用新的字体大小。如果网络较慢，用户会先看到内容被压缩或放大，然后突然跳变到正确尺寸，这就是 FOUC。相比之下，vw 是原生 CSS 属性，浏览器在渲染初期即可直接计算像素值，无需任何脚本介入，保证了首屏渲染的平滑性。
立即学习“前端免费学习笔记（深入）”；
在复杂媒体查询场景下，vw 与 rem 的维护成本有何差异？
在需要针对特定断点调整布局的场景中，rem 通常需要在 Media Query 中重新定义根字体大小，这会导致全局样式连锁反应，维护成本高且容易出错。而 vw 本身具有天然的连续性，虽然它不能像 rem 那样通过改变根字体来批量控制所有子元素，但现代开发中常结合 clamp() 函数来解决极小或极大屏幕下的可读性问题，使得 vw 在保持灵活性的同时降低了维护复杂度。
/* 使用 vw 配合 clamp 实现最佳体验 */
html {
font-size: clamp(16px, 2vw, 24px);
}
.container {
width: 90vw;
max-width: 1200px;
padding: 2vw;
}这段代码展示了 vw 在现代布局中的实际用法。font-size 使用 clamp 限制了最小和最大字号，确保在小屏手机上文字不会过小，在大屏平板上也不会过大。而 .container 的宽度和内边距直接使用 vw，实现了随视口线性伸缩。与 rem 方案相比，这里不需要编写任何 Media Query 来调整根字体，也不需要担心 JS 执行顺序。开发者只需关注设计稿的比例关系，代码更直观，且在 Safari、Chrome 等主流浏览器中均得到良好支持。对于大多数移动端 H5 页面，这种纯 CSS 的解决方案在稳定性和开发效率上均优于传统的 rem + JS 模式。
