大厂前端抛弃px和rem主因是vw+clamp()能实现无闪动、无JS依赖的流体布局，且边界可控、兼容性完备；rem需JS动态设根字号易致布局抖动，缩放逻辑在高DPR设备上失真，维护成本更高。
Rem 布局在现代浏览器中已不是首选，核心原因不是它“不能用”，而是 viewport 单位（vw/vh）配合 clamp() 能更直接、更稳定地实现流体缩放，且无需 JS 干预。
rem 依赖 JS 动态设置根字号，容易出现布局闪烁
rem 的缩放逻辑必须靠 JavaScript 运行时计算 document.documentElement.style.fontSize。如果 JS 加载慢、执行晚，或被阻塞（比如首屏渲染前 JS 未就绪），页面会先按默认 16px 渲染，再突然跳变——这就是常说的“字体闪一下”或“布局抖动”。
而 vw 是纯 CSS 单位，浏览器在样式解析阶段就完成计算，无延迟、无依赖。
常见错误现象：
• 页面刚打开时文字巨大或极小，0.3 秒后恢复正常
• 在低端安卓 WebView 或 iOS Safari 隐私模式下，flexible.js 甚至可能完全不执行
• 使用 SSR 或微前端时，JS 初始化时机难统一，rem 值在客户端和服务端不一致
vw + clamp() 比 rem 更精准控制响应边界
单纯写 font-size: 5vw 确实会失控：小屏字太小，大屏字太大。但 clamp() 天然就是为解决这个问题设计的：font-size: clamp(14px, 5vw, 28px);
这个表达式意味着：最小不小于 14px，最大不超过 28px，中间按 5vw 流动缩放。
rem 方案想做到类似效果，得靠多层媒体查询 + 多套根字号设定，配置复杂且断点生硬。
使用场景差异：
• To C 类产品（电商、资讯、社交）需要丝滑缩放体验 → vw + clamp() 是事实标准
• 后台系统、内部工具对可访问性要求高，且屏幕尺寸集中 → rem 仍可接受，但没必要强推
• postcss-px-to-viewport 插件能自动把写死的 16px 转成 clamp(14px, 4.266667vw, 16px)，rem 的“手动换算”优势早已消失
viewport 单位兼容性已无实质障碍
2022 年起，所有主流移动端浏览器（Chrome for Android、Safari iOS 11+、Firefox、Edge）都已完整支持 vw/vh，包括对 visualViewport 的响应支持。
过去 rem 被推崇，本质是为绕开老版本 Safari 对 vw 的 bug（如横竖屏切换后不重算）。这些 bug 在 iOS 13+ 和 Android Chrome 80+ 中均已修复。
现在还坚持用 rem，往往是因为：
• 项目历史包袱重，没做迁移评估
• 团队对 clamp() 语法不熟，误以为“vw 就是没上限”
• 错把“rem 支持 font-size 缩放”当成优势——但现代浏览器对 rem 和 em 的缩放行为已与 px 一致，无障碍支持并不依赖 rem
rem 的“等比缩放”在高 DPR 设备上反而失真
rem 方案常按“设计稿宽度 / 10”设根字号（如 375px 设计稿 → html { font-size: 37.5px; }），但这忽略了设备像素比（DPR）。
例如 iPhone 13（DPR=3）实际物理像素是 1170×2532，但视口宽度仍是 390px —— rem 计算只认 CSS 像素，不感知 DPR。
而 vw 天然基于视口宽度（document.documentElement.clientWidth），与 DPR 无关，缩放结果更符合视觉预期。
容易踩的坑：
• 在 DPR > 2 的设备上，rem 布局文字边缘发虚（因字体被非整数倍缩放）
• 使用 window.devicePixelRatio 手动补偿 rem，反而让逻辑更重、更难维护
• vh 在 iOS Safari 中曾有全屏视频退出后高度异常的问题，但 iOS 15.4+ 已修复，当前可放心使用
真正难的是把 clamp() 的三值关系调准：MIN 要保障最小可读性（通常不低于 14px），PREFERRED 要匹配设计稿视觉节奏（比如 375px 下 16px → 4.266667vw），MAX 要防止超大屏溢出（比如限制在 24px 或 28px）。这需要结合真实设备测试，而不是套公式。
