rem在移动端适配中越来越难用，因其依赖根元素font-size动态计算，而现代浏览器、系统字体缩放、无障碍设置、横竖屏切换及webview容器行为差异大，导致js动态设置极易失准。
rem 在移动端适配中为什么越来越难用
因为 rem 依赖根元素 font-size 动态计算，而现代浏览器和系统对字体缩放、无障碍设置、横竖屏切换、WebView 容器行为的支持差异越来越大，导致基于 document.documentElement.style.fontSize 的 JS 动态设置极易失准。
常见错误现象包括：横屏时文字突然变小、开启系统「更大字体」后布局错乱、iOS Safari 某些版本下 rem 计算值被强制重置、微信内置 WebView 中 rem 偶发不响应 JS 设置。
- 不是所有 WebView 都支持
document.documentElement.style.fontSize实时生效（尤其 Android 低版本 X5 内核） - 用户手动调整系统字体大小时，
rem基准会被覆盖，但多数项目没做 fallback 处理 -
rem无法响应 viewport 缩放（如双指 pinch-zoom），而用户确实会这么做
vw/vh + calc() 替代 rem 的实际写法
直接用视口单位更贴近“按屏幕宽度等比缩放”的原始需求，且无需 JS 干预根字体大小。主流做法是：以 375px 设计稿为基准，1rem = 100px → 实际换算为 100vw / 3.75，即 1rem ≈ 26.666vw；但更稳妥的是用 calc() 配合媒体查询兜底。
例如设置一个 16px 字体（设计稿中）：
.title {
font-size: calc(100vw / 3.75 * 0.16); /* 16 / 100 = 0.16 */
}
注意：不要无脑全量替换，vw 在小屏上可能过小（如 320px 屏幕下 16px 变成 ~13.6px），需加 min-width 限制或搭配 @media。
- Android Chrome 62+、iOS Safari 9+ 均原生支持
vw，兼容性已无硬伤 - 避免在
padding、margin等非文本属性中滥用vw，易导致父子容器尺寸嵌套偏差 - 若需兼容老 WebView（如某些银行 App 内置），可保留
rem作为降级，但主逻辑走vw
postcss-pxtorem 插件现在还安全吗
不安全。该插件本质是构建时把 px 转成 rem，但它假设运行时根字号恒定，而现代系统字体设置、WebView 渲染策略、甚至 PWA 的 standalone 模式都会打破这个假设。
典型问题：postcss-pxtorem 把 12px 转成 0.75rem，但若用户系统字体设为「较大」，实际 1rem 可能变成 24px，导致文字放大一倍——这不是适配，是失控。
- 它无法感知运行时
text-size-adjust或-webkit-text-size-adjust的影响 - 与 CSS 自定义属性（
--base-font-size）混用时，插件无法识别变量计算路径 - Vue/React 组件库中若用了
rem单位，一旦父组件动态改了html字号，子组件样式可能不重绘
真正需要关注的不是单位，而是缩放意图
用户缩放字体，是希望内容更易读；用户旋转屏幕，是希望空间被重新分配；用户进入分屏模式，是希望界面自适应新容器。这些都不是 rem 能表达的语义。
现代方案倾向组合使用：clamp() 控制字号弹性区间、container queries 响应局部容器、media queries 区分设备能力、必要时用 JS 监听 visualViewport 或 matchMedia。
比如一个按钮字号，与其写 font-size: 1.2rem，不如：
button {
font-size: clamp(14px, 4vw, 18px);
}
这行代码明确表达了：最小 14px、最大 18px、中间随视口线性变化——既防小屏过小，也防大屏溢出，还不受系统字体干扰。
复杂点在于：不同组件对缩放的容忍度不同，标题可以弹性大些，表单控件则需保底清晰度；这些细节没法靠一种单位通吃，得按场景拆解。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
