应优先用vw替代rem做容器级适配，rem保留用于字体层级和内边距；vw无JS依赖但需注意PC滚动条溢出及系统放大不响应问题，rem适合老旧WebView兼容场景。
rem 依赖 JS 动态设置 font-size，页面可能闪一下
很多项目用 flexible.js 或自写脚本在 里改 document.documentElement.style.fontSize，但 JS 执行有延迟：HTML 解析到一半时样式已开始渲染，而此时 font-size 还是默认值（通常是 16px），导致文字/盒子突然放大或错位——这就是“布局闪烁”。
常见现象包括：
- 首屏文字先巨大后缩回
- 按钮宽度跳变、图标位置偏移
- 某些安卓 WebView 中甚至不触发 resize，
font-size始终不变
规避方法不是加 setTimeout，而是放弃运行时计算。如果必须用 rem，至少把初始化逻辑塞进 <script></script> 标签并放在 最顶部，且避免异步加载。
vw 单位直接由浏览器计算，无 JS 依赖，但要注意 PC 端滚动条宽度
100vw 在有垂直滚动条的 PC 页面中，实际宽度 = 视口宽度 + 滚动条宽度（通常 17px 左右），这会导致 width: 100vw 的元素溢出容器。移动端因滚动条不占位，基本无此问题。
立即学习“前端免费学习笔记（深入）”；
使用建议：
- 移动端 H5 项目可放心用
vw替代rem做宽度/字体适配 - PC 端若需兼容，优先用
width: 100%或媒体查询兜底 - 字体大小慎用过大
vw值（如font-size: 8vw），小屏下会变成 12px 以下，影响可读性 - 构建阶段用
postcss-px-to-viewport转换更稳，比如配置viewportWidth: 375，写width: 75px自动转成width: 20vw
rem 仍适合控制字体层级和内边距比例，vw 更适合容器级流式缩放
两者不是非此即彼的关系。真实项目中混用更合理：
- 用
vw控制大块区域宽度（.banner、.card）、全屏高度（min-height: 100vh） - 用
rem控制文字大小（font-size: 1.125rem）、行高（line-height: 1.5rem）、内边距（padding: 0.5rem），便于统一调整字号体系 - 绝对不能用
rem控制 border 或阴影，否则缩放后边框变粗、模糊 - 避免
em嵌套多层，它会继承父级font-size，容易失控
现代项目该选哪个？看目标环境和构建能力
截至 2026 年，Android 5+ 和 iOS 9+ 已覆盖绝大多数用户，vw 兼容性不再是障碍。但关键不在兼容性，而在可控性：
- 如果你用 Vue/React + Webpack/Vite，有构建工具链，
postcss-px-to-viewport或vite-plugin-vue-jsx配合vw是首选 - 如果项目要支持老旧 WebView（如部分银行/政务 App 内嵌页），rem + 媒体查询仍是稳妥选择
- 纯静态页或无法接入构建流程的场景，
vw依然比硬塞一段 JS 更干净
真正容易被忽略的是：vw 字体在系统强制放大（如 iOS「更大字体」辅助功能）下不会响应，而 rem 会——这点对无障碍要求高的项目必须提前验证。
