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必须写:,否则 iOS 会强制放大文本,rem 基准再准也没用 - 千万别加
minimum-scale或maximum-scale以外的缩放限制,否则微信内嵌浏览器可能无法触发放大 - 有些老项目用
viewport width=750强制缩放,这和 rem 方案冲突——rem 要求 viewport 是device-width,否则clientWidth拿到的是缩放后的宽度,计算就全乱了
实际项目里最常出问题的,不是 rem 算不对,而是忘了在页面初始化完成前就渲染了 DOM,或者把 border、line-height 这类不该缩放的属性也塞进了 rem 体系。留个心眼:只要看到某块区域在 iPhone 上突然变细或文字挤在一起,先查这两处。
前端入门到VUE实战笔记:立即使用
在学习笔记中,你将探索 前端 的入门与实战技巧!











