rem基准值必须动态计算，不能写死；需用JS按“当前屏幕宽度÷设计稿宽度×基准数”公式实时设置根字体大小，并在DOMContentLoaded后立即执行且监听resize和orientationchange事件。
rem基准值必须动态计算，不能写死
直接在CSS里写 html { font-size: 16px } 或 100% 就等于放弃适配——它在iPhone SE和iPad上显示完全一样，根本不是“等比缩放”。真正起作用的是JS动态算出来的值，公式本质是：当前屏幕宽度 ÷ 设计稿宽度 × 基准数。
常见错误现象：页面刚加载时尺寸正常，横屏后文字突然变小、按钮错位；或安卓WebView里字体忽大忽小。
- 推荐用
document.documentElement.clientWidth / 375 * 100（设计稿宽375px）或/ 750 * 100（设计稿宽750px），结果单位必须是px - 执行时机：必须在
DOMContentLoaded后立即执行一次，再监听resize和orientationchange - 兼容性补丁：iOS Safari可能不触发初始
resize，建议加一句setTimeout(() => { reCalc() }, 0)强制兜底 - 禁用
vw直接设根字号（如font-size: 10vw），部分安卓WebView解析不准，会导致闪动或失真
哪些CSS属性该用rem，哪些坚决不能碰
rem不是万能缩放器，混用会破坏视觉一致性，尤其在嵌套和缩放叠加场景下。
典型错误现象：行高用 line-height: 1.5rem 导致文字行距随屏幕缩放异常拉大；border用 border: 0.02rem solid #ccc 在小屏下渲染成虚线甚至消失。
立即学习“前端免费学习笔记（深入）”；
- 该用：
font-size、width/height、margin/padding、border-radius - 禁用：
line-height（用无单位数值，如1.5）、border-width（固定用1px）、transform: scale()、box-shadow偏移量 - 背景图尺寸、图标字体大小慎用rem——它们依赖像素精度，缩放后容易模糊或错位
px转rem别靠手动算，工具链要选对
写 12px → 0.12rem（按1rem=100px）这种换算，三天就手抖出bug。但工具选错反而更麻烦。
常见错误现象：Webpack的 px2rem-loader 把转换硬编码进CSS文件，设计稿基准从750px改成375px就得全量重编；VS Code插件只支持反向转换，开发时毫无用处。
- PostCSS方案首选
postcss-pxtorem，但必须关掉rootValue自动检测，显式设为100（对应1rem = 100px） - 禁止用“自动读取浏览器默认字号”类配置，它会把16px当基准，和你JS里设的100px冲突
- 设计稿标注是750px宽、切图按2x出，那开发中直接按1rem = 100px换算，不用额外除2——刚好对齐100dp
viewport设置和rem不是一回事
很多人以为加了 <meta name="viewport" content="width=device-width"> 就万事大吉，其实它只管页面初始缩放比例，rem管的是元素尺寸缩放逻辑，两者职责完全不同。
容易被忽略的点：viewport没设 user-scalable=no 时，用户双指缩放会干扰rem基准；iOS系统级“更大字体”设置也会强制放大根字号，导致rem计算失效。
-
viewport必须包含width=device-width，且避免设initial-scale（除非你真要禁用缩放） - rem失效时先检查是否漏了viewport，再查JS是否执行、是否被其他脚本覆盖
document.documentElement.style.fontSize - 复杂场景（如Webview嵌套、iframe内页）建议加一层
getComputedStyle(document.documentElement).fontSize校验实际生效值
