rem基准值应动态计算：document.documentElement.style.fontSize = clientWidth / 750 * 100 + 'px'，在DOMContentLoaded后执行并监听resize/orientationchange；避免用vw或固定值；rem仅用于字号、边距、宽高、圆角；line-height、border等禁用rem；viewport须设width=device-width且不缩放。
rem 基准值怎么设才不翻车
直接用 html 的 font-size 控制 rem 基准，但不能写死成 16px 或 100%——这样在不同设备上不会缩放。必须用 JS 动态算，或者用媒体查询兜底。
- 推荐方案：按设计稿宽度（比如 750px）等比计算，
document.documentElement.style.fontSize = document.documentElement.clientWidth / 750 * 100 + 'px' - 注意时机：要在
DOMContentLoaded后执行，且监听resize和orientationchange，否则横竖屏切换或加载后窗口变化时失效 - 兼容性坑：iOS Safari 在页面刚加载时可能还没触发
resize，建议加一次立即执行 - 不要用
vw直接设html font-size（如font-size: 10vw），某些安卓 WebView 对vw解析不准，导致字体忽大忽小
哪些地方该用 rem，哪些不该碰
rem 本质是缩放单位，只适合控制「尺寸类」属性；混用会破坏一致性，尤其别在布局逻辑里掺和。
- 该用：字号（
font-size）、边距（margin/padding）、宽高（width/height）、圆角（border-radius） - 不该用：行高（
line-height）设成 rem 容易叠加缩放，建议用无单位数值（如1.5）；背景图尺寸、阴影偏移、transform 缩放也尽量避开 rem - 特别注意：
border宽度如果用 rem，在小屏下可能缩到看不见，建议固定用px（如border: 1px solid #ccc）
px 转 rem 工具链怎么配才省事
手动算 12px → 0.12rem（按 100px=1rem）太容易错，但工具链选错反而更麻烦。
- PostCSS 推荐用
postcss-pxtorem，但务必关掉rootValue自动检测，显式设为100（对应 1rem = 100px），避免它读取浏览器默认字号 - VS Code 插件如
CSS Rem to Px只能反向转换，日常开发中意义不大；真正要的是「写 px 自动转 rem」，得靠保存时自动处理 - 警惕 Webpack loader 类方案（如
px2rem-loader）：它会在构建时硬编码转换，一旦设计稿基准变了就得全量重编，不如 PostCSS 灵活 - 设计稿标注如果是 750px 宽，切图时按 2x 出，那开发中 1rem = 100px 就刚好对应 100dp，不用额外除 2
viewport 设置和 rem 是什么关系
很多人以为设了 viewport 就不用 rem 了，其实它俩管的事完全不同：前者控制页面初始缩放比例，后者控制元素尺寸缩放逻辑。
立即学习“前端免费学习笔记（深入）”；
-
viewport必须写：<meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=no">，否则 iOS 会强制放大文本，rem 基准再准也没用 - 千万别加
minimum-scale或maximum-scale以外的缩放限制，否则微信内嵌浏览器可能无法触发放大 - 有些老项目用
viewport width=750强制缩放，这和 rem 方案冲突——rem 要求 viewport 是device-width，否则clientWidth拿到的是缩放后的宽度，计算就全乱了
实际项目里最常出问题的，不是 rem 算不对，而是忘了在页面初始化完成前就渲染了 DOM，或者把 border、line-height 这类不该缩放的属性也塞进了 rem 体系。留个心眼：只要看到某块区域在 iPhone 上突然变细或文字挤在一起，先查这两处。
