rem适配必须动态设置根字体大小，因rem是相对于html font-size的相对单位，静态媒体查询难覆盖全机型；需用JS根据screen.width或clientWidth计算并设置documentElement.style.fontSize，如750px设计稿下iPhone 12设为52px；vw可替代但存在iOS键盘缩放、安卓舍入误差等问题；混用px/rem易致UI组件失真，viewport meta缺失会导致计算基准错误。
rem适配为什么必须配合根字体大小动态计算
不改html元素的font-size，rem就只是个固定倍数单位，和px没本质区别。移动端屏幕宽度千差万别，靠CSS媒体查询写死几档font-size既难覆盖全面，又容易在中等尺寸设备上断层。
实际做法是用JS在页面加载初期读取window.screen.width或document.documentElement.clientWidth，算出比例后直接设置document.documentElement.style.fontSize。常见方案是按750px设计稿等比缩放：比如iPhone 12（390px宽）对应390 / 750 * 100 = 52px，那么1rem就≈52px。
- 别用
window.innerWidth——横竖屏切换时它不触发重排，值可能滞后 - 初始化时机要早，最好放在
<head>里的内联脚本，避免FOUC（闪动） - 记得监听
resize和orientationchange，但别高频触发，加节流
vw单位能替代JS计算rem吗
能，但有兼容和精度问题。100vw始终等于视口宽度，所以html { font-size: 3.75vw; }在750px设计稿下刚好是28.125px（750×0.0375），接近常用基准值。这确实省了JS逻辑。
问题在于：iOS Safari在唤起键盘时会把vw按“视觉视口”计算，导致font-size骤然缩小；安卓部分浏览器对小数vw渲染有舍入误差，连续嵌套rem会放大偏差。
立即学习“前端免费学习笔记（深入）”；
- 若只做简单字号/间距适配，
vw够用；涉及高度、圆角、border等需严格比例的场景，建议回退到JS方案 - 不要写
html { font-size: 100vw / 7.5; }——CSS不支持运算符，必须预计算好数值 -
vw方案下，1rem≈10px的设计习惯要同步调整，否则开发时换算易错
px与rem混用时哪些地方最容易崩
最典型的是CSS框架组件（如Ant Design Mobile）或第三方UI库，它们内部大量使用px写死尺寸。一旦你全局改了html的font-size，这些组件的按钮、弹窗、图标就会同比例缩放，但往往没同步调整内部line-height、padding或transform偏移量，结果就是文字溢出、点击热区错位。
- 优先查文档：像
lib-flexible已废弃，postcss-pxtorem插件配置里要排除node_modules路径 - 绝对定位元素慎用
rem——父容器font-size变化时，它的top/left不会自动重算 - Canvas、SVG内联样式中的
px值不受rem影响，但用getComputedStyle读取时会转成px，容易误判
viewport meta标签漏写会怎样
没有<meta name="viewport" content="width=device-width, initial-scale=1.0">，iOS Safari默认以980px宽度渲染页面，此时document.documentElement.clientWidth返回980，JS算出来的font-size会严重失真——比如在iPhone上算出130px，1rem变成手机屏幕宽度的1.3倍。
- 这个meta必须写在
<head>最前面，且不能被JS动态插入（iOS不认） - 别加
maximum-scale或user-scalable=no——不仅影响可访问性，某些安卓WebView会因此禁用双指缩放，导致vw计算异常 - 如果项目要支持横屏，
width=device-width足够，不用额外监听orientationchange去改meta
真正麻烦的从来不是怎么写代码，而是不同设备对同一行CSS的解释差异——比如Android 4.4的WebView把100vw算成包括滚动条宽度，而Chrome 80之后已修正。这类细节，不真机测三轮以上根本发现不了。
