移动端适配这件事，说大不大，说小也不小。我见过不少项目，PC端跑得稳稳当当，一到手机上就原形毕露：字体忽大忽小、按钮挤成一团、图片要么溢出要么留白一大片。更让人头疼的是，团队里每个人对"适配"的理解都不一样，有人用百分比，有人用弹性盒子，还有人干脆写死像素值，最后拼出来的页面在各类机型上表现参差不齐。rem这套方案之所以值得单独拿出来讲，是因为它用一套非常朴素的思路，把"设计稿尺寸"和"设备实际宽度"之间的换算关系给统一了。你只要理解了根字号这个杠杆，剩下的都是机械操作。这篇文章我会从 rem 的本质讲起，把动态根字号的几种主流做法拆开对比，再补上实际项目里最容易翻车的几个细节，包括 1px 边框、字体缩放、横竖屏切换这些老生常谈但又绕不开的问题。不管你是刚接触移动端的新手，还是想把手头项目适配方案梳理一遍的老手，应该都能从中找到能直接用的东西。

1. rem 到底在解决什么问题，以及它和 em、px 的本质区别

1.1 从一次真实的适配翻车说起

早些年我接手过一个活动页项目，设计稿给的是 750px 宽度，标注得清清楚楚。当时图省事，所有尺寸直接按标注写死 px，在模拟器上看效果完美。结果上线后收到反馈：小屏手机上标题挤成两行，大屏手机上内容缩在左上角一小块，留白大得离谱。问题的根源很直白——px 是绝对单位，它不会随设备宽度变化。你在 375px 宽的设备上写font-size: 32px，它占的比例是 32/375；换到 414px 宽的设备上，同样的 32px 占比就变成了 32/414，视觉上明显变小了。设计稿是按固定宽度画的，但设备宽度是浮动的，这两者之间缺一个换算桥梁。

em看起来能解决这个问题，因为它相对父元素字号。但 em 有个要命的连锁反应：父元素字号一变，子元素全部跟着变，嵌套层级一深，计算就变成了一场灾难。你写padding: 1em，这个 1em 到底等于多少像素，得一层层往上追溯父元素的 font-size，维护成本极高。rem的 r 是 root 的意思，它只认根元素html的字号，不管嵌套多深，1rem 永远等于 html 的 font-size。这一刀切的设计，恰恰是它适合做全局适配的根本原因。

1.2 根字号就是那把统一的尺子

把 rem 理解成"一把会伸缩的尺子"最直观。假设你把 html 的 font-size 设成 16px，那 1rem 就是 16px，2rem 就是 32px。现在你把 html 的 font-size 改成 20px，所有用 rem 写的尺寸会等比例放大 1.25 倍。页面里所有元素共用同一把尺子，整体缩放时比例关系不会乱。这就是 rem 适配的核心机制：用 JavaScript 动态修改根字号，让 1rem 所代表的实际像素值随屏幕宽度线性变化。

具体到数值关系，假设设计稿宽度是 750px，你在稿子上量到某个元素宽 150px。如果约定 1rem 对应设计稿上的 75px（也就是把设计稿分成 10 份），那这个元素就是 2rem。到了实际设备上，屏幕宽 375px，你把根字号设成 375/10 = 37.5px，那 2rem 实际渲染出来就是 75px，正好占屏幕宽度的 1/5，和设计稿上的比例完全一致。整个换算链条里，唯一需要动态计算的就是根字号，其余尺寸全部写成 rem 固定值，一次写完，处处适配。

1.3 三种单位的适用边界对照

这张表不是让你死记，而是提醒一个判断原则：需要跟屏幕宽度成比例变化的，用 rem；需要保持物理尺寸稳定的，用 px。比如 1px 的细边框，你要的是它在任何屏幕上都看起来是"一根细线"，而不是随屏幕放大成粗线，这种就该用 px 或者后面会讲的缩放方案，而不是 rem。

2. 动态根字号的三种主流写法与选型逻辑

2.1 方案一：JS 监听 resize 直接算

最原始也最透明的做法，就是在页面加载和窗口尺寸变化时，用 JavaScript 读取document.documentElement.clientWidth，除以一个约定好的份数，把结果赋给 html 的 font-size。代码大致是这样：

(function () { function setRootFontSize() { var clientWidth = document.documentElement.clientWidth || window.innerWidth; // 设计稿 750px，分成 10 份，每份 75px var rootSize = clientWidth / 10; document.documentElement.style.fontSize = rootSize + 'px'; } setRootFontSize(); window.addEventListener('resize', setRootFontSize); window.addEventListener('orientationchange', setRootFontSize); })();

这段代码的好处是一目了然，出了问题你能立刻定位到是哪一行算错了。但它的短板也很明显：resize事件在移动端触发频率很高，尤其是拖动浏览器地址栏收起展开的时候，会连续触发几十次，每次都改根字号会引起大量重排。稳妥的做法是加一层防抖，或者用requestAnimationFrame把多次调用合并到一帧里执行。另外orientationchange在部分老机型上触发时机不可靠，横竖屏切换后拿到的宽度可能是旧值，需要延迟一小段时间再读一次。

2.2 方案二：CSS 媒体查询分段设置

不想引入 JS 的话，可以用媒体查询按常见屏幕宽度分段写死根字号：

html { font-size: 20px; } @media screen and (min-width: 375px) { html { font-size: 25px; } } @media screen and (min-width: 414px) { html { font-size: 27.6px; } } @media screen and (min-width: 750px) { html { font-size: 50px; } }

这种写法的优点是纯 CSS、无脚本依赖，首屏不会因为 JS 未执行而出现字号跳变。缺点是它是阶梯式的，屏幕宽度在两个断点之间时，根字号是固定的，适配精度不如连续计算。而且断点越多维护越麻烦，遇到折叠屏、平板这些非标准宽度，很容易落在某个断点里表现不佳。我的经验是，如果项目对适配精度要求不高、页面结构简单，媒体查询够用；但凡涉及复杂布局和精细还原，还是得上 JS 连续计算。

2.3 方案三：结合视口单位的混合思路

vw是视口宽度的百分之一，1vw 等于屏幕宽度的 1%。有人会想，那直接html { font-size: 10vw; }不就行了，纯 CSS 搞定。思路没错，但vw在部分浏览器里对滚动条宽度的处理不一致，而且当根字号完全由 vw 决定时，用户手动调整系统字体大小的设置会被忽略，无障碍体验打折扣。更稳的混合做法是：用 JS 算出根字号后，再乘一个用户偏好系数，或者用clamp()给根字号设一个上下限，防止在超宽屏上字号大到离谱、在超小屏上小到看不清。

html { font-size: clamp(12px, 2.6667vw, 50px); }

这行的意思是根字号最小 12px、最大 50px，中间按 2.6667vw 走（对应 375px 屏下约 10px 的基准，可按设计稿调整）。clamp()的兼容性现在主流机型都没问题，用它兜底能省掉不少边界判断。

2.4 选型的判断依据

三种方案没有绝对优劣，关键看你的约束条件。我一般按这几条来定：项目是否允许引入额外脚本、首屏渲染对字号跳变是否敏感、设计稿宽度是否统一、是否需要支持用户系统字号缩放。如果设计稿是 750px 且团队统一，JS 连续计算最省心；如果是多套设计稿混用，媒体查询分段反而更好控制；如果追求零脚本和首屏稳定，clamp()加 vw 是折中优选。选型时把这些条件列清楚，比盲目抄某篇教程靠谱得多。

3. 从设计稿到代码：rem 换算的完整落地流程

3.1 先定基准，再谈换算

换算的第一步不是写代码，而是和设计确认一个基准关系。常见约定有两种：一是"设计稿宽度 / 10 = 1rem 对应的设计稿像素"，750px 稿就是 75px 对应 1rem；二是"设计稿宽度 / 100"，750px 稿就是 7.5px 对应 1rem。前者数值好记，后者精度更高、小数更少。我倾向用除以 10 的方式，因为 75 这个数在口算时比较友好，量到 150px 就是 2rem，量到 225px 就是 3rem，心算不容易出错。

定了基准之后，实际设备上的根字号公式就是：根字号 = 设备宽度 / 设计稿份数。750px 稿分 10 份，375px 设备上根字号就是 37.5px，414px 设备上就是 41.4px。这个公式要写进团队文档，所有人按同一套来，否则有人按 75 算、有人按 7.5 算，页面比例立刻乱套。

3.2 换算工具与手动计算的取舍

设计稿上标注的尺寸是 px，代码里要写 rem，中间需要一个除法。手动算当然可以，150 / 75 = 2，225 / 75 = 3，但遇到 137px 这种除不尽的就麻烦了，137 / 75 = 1.8266...，写进代码里一长串小数既难看又容易出错。实际项目里我一般用两种方式处理：一是用构建工具里的插件自动把 px 转成 rem，写代码时照抄设计稿标注，编译时统一转换；二是用编辑器插件或在线换算表，量一个转一个。

自动转换的配置要点在于基准值要和 JS 里的份数严格对应。比如 JS 里是clientWidth / 10，那转换插件的基准就得设成设计稿宽度 / 10 = 75。这两处一旦对不上，页面会整体放大或缩小一个固定倍数，而且这种错误在单一机型上不容易发现，往往要换几台设备对比才暴露出来。我踩过这个坑，当时插件基准设成了 37.5，JS 里却除以 10，结果所有元素小了一半，排查了半天才定位到是配置不一致。

3.3 哪些属性该转、哪些不该转

不是所有 px 都该无脑转成 rem。我的划分原则是这样的：

• 该转 rem 的：容器宽高、内外边距、字号、行高、圆角、大部分间距类属性。这些需要跟屏幕宽度成比例，转 rem 后整体缩放才协调。
• 不该转 rem 的：1px 边框、极细分割线、阴影偏移量中的细微值、以及需要保持物理尺寸的图标描边。这些如果转成 rem，在小屏上可能细到看不见，在大屏上又粗得突兀。
• 视情况而定的：图片宽高。如果图片需要铺满容器，用百分比或width: 100%更合适；如果是固定比例的图标，用 rem 控制尺寸可以，但要配合object-fit防止变形。

这个划分不是死规矩，但能帮你避开大部分"整体缩放后局部比例失调"的问题。尤其是边框，后面第 5 节会专门讲 1px 的处理方案。

3.4 一个完整的换算示例

假设设计稿 750px，某卡片标注：宽 690px、内边距 30px、标题字号 36px、圆角 12px、边框 1px。按 75px 对应 1rem 换算：

.card { width: 9.2rem; /* 690 / 75 */ padding: 0.4rem; /* 30 / 75 */ border-radius: 0.16rem; /* 12 / 75 */ border: 1px solid #e5e5e5; /* 边框保持 px */ } .card__title { font-size: 0.48rem; /* 36 / 75 */ }

在 375px 设备上，根字号 37.5px，卡片实际宽 9.2 × 37.5 = 345px，正好是屏幕宽度的 92%，和设计稿上 690/750 = 92% 的比例完全吻合。这就是 rem 适配想要达到的效果——比例一致，而非像素一致。

4. 实际项目里最容易翻车的几个细节

4.1 根字号被浏览器最小字号限制截断

这是最隐蔽的坑之一。部分浏览器有"最小字号"设置，比如默认不小于 12px。当你按公式算出来的根字号小于这个值时（比如在 320px 小屏上，320 / 10 = 32px 还好，但如果份数设成 100，320 / 100 = 3.2px 就完蛋了），浏览器会强行把根字号拉到最小值，导致所有 rem 尺寸集体偏大，页面比例全乱。解决办法有两个：一是份数别设太大，保证最小屏上根字号也大于 12px；二是用clamp()给根字号设下限，同时接受小屏上比例略有偏差的事实。我一般选前者，份数控制在 10 左右，320px 屏上根字号 32px，安全。

4.2 横竖屏切换后的重算时机

手机横过来之后，clientWidth变成了原来的高度值，根字号需要重算。但orientationchange事件触发时，部分浏览器还没完成布局更新，此时读到的宽度可能是旧值。稳妥做法是在事件回调里加一个短延迟，或者监听resize并在requestAnimationFrame里读取：

window.addEventListener('orientationchange', function () { setTimeout(setRootFontSize, 100); });

这个 100ms 不是随便定的，是给浏览器留出完成视口更新的时间。延迟太短读到旧值，太长用户会看到明显的字号跳变。实测下来 100ms 左右在主流机型上比较稳。

4.3 字体大小与 rem 的联动陷阱

字号用 rem 写，意味着用户无法通过系统设置放大字体——因为根字号被 JS 锁死了。这对无障碍不友好。折中方案是：布局尺寸用 rem，正文文字用px或em配合媒体查询，或者给根字号乘一个用户偏好系数。有些团队会在 JS 里读取window.getComputedStyle的初始字号作为基准，再叠加缩放，但这套逻辑在不同浏览器上表现不一，实现成本较高。我的建议是，正文可读性优先的场景，字号别完全交给 rem，至少保留媒体查询做兜底放大。

4.4 第三方组件的 rem 污染

引入的 UI 组件库如果内部也用 rem，而它的基准和你项目的基准不一致，就会出现组件尺寸和页面其他部分对不上的情况。这种问题排查起来很费劲，因为样式是组件库内部写的。应对办法是：优先选支持主题定制的组件库，把它的 rem 基准改成和你一致；或者用 CSS 变量把根字号抽出来，组件库引用同一个变量。实在改不动的，就在组件外层包一个容器，用font-size重置局部基准，把组件隔离在一个独立的 rem 上下文里。

5. 1px 边框与高清屏：rem 方案绕不开的补丁

5.1 为什么 1px 在高清屏上会变粗

rem 适配解决的是比例问题，但 1px 边框是另一个维度的事。在设备像素比（DPR）为 2 或 3 的高清屏上，CSS 里的 1px 会被渲染成 2 个或 3 个物理像素，视觉上就是一条粗线。设计稿上那条精致的细分割线，到了真机上变得笨重。这个问题和 rem 无关，但移动端适配绕不开它，所以必须一并处理。

5.2 几种主流处理方案的对比

我实际项目里用得最多的是伪元素加transform: scaleY(0.5)这套，因为它兼容性最稳，视觉上也最接近设计稿。核心思路是：给元素加一个绝对定位的伪元素，高度设为 1px，然后用transform沿 Y 轴缩放一半，再通过transform-origin控制缩放基点，让线贴在正确的位置。

.hairline-bottom { position: relative; } .hairline-bottom::after { content: ''; position: absolute; left: 0; bottom: 0; width: 100%; height: 1px; background-color: #e5e5e5; transform: scaleY(0.5); transform-origin: 0 100%; }

5.3 媒体查询按 DPR 分档的写法

如果项目需要更精细的控制，可以按设备像素比用媒体查询分档处理：

@media (-webkit-min-device-pixel-ratio: 2), (min-resolution: 2dppx) { .hairline-bottom::after { transform: scaleY(0.5); } } @media (-webkit-min-device-pixel-ratio: 3), (min-resolution: 3dppx) { .hairline-bottom::after { transform: scaleY(0.333); } }

这样在 DPR 为 3 的设备上，1px 的线缩放成 0.333，物理上正好是 1 个像素，视觉上就是最细的线。需要注意的是，缩放后的线在部分机型上可能出现颜色偏淡，这是因为亚像素渲染导致的，可以通过调整背景色透明度来补偿。

6. 适配方案的上线前自检清单

6.1 多机型实测的覆盖策略

rem 方案在模拟器上看着对，不代表真机就对。上线前我一般会覆盖这几类设备做实测：小屏（320px 到 360px 宽）、主流屏（375px 到 414px）、大屏（430px 以上）、以及至少一台折叠屏或平板。每类设备上重点看三件事：整体比例是否协调、文字是否清晰可读、边框和分割线是否正常。模拟器只能验证逻辑，真机才能暴露渲染差异，尤其是安卓阵营机型碎片化严重，同一套代码在不同厂商的浏览器内核上表现可能不同。

6.2 关键指标的核对方法

实测时我会打开浏览器的开发者工具，用元素检查逐个核对：根字号的实测值是否等于"设备宽度 / 份数"、关键容器的宽度占比是否和设计稿一致、字号换算后是否落在可读区间（正文不小于 12px 实际渲染值）。如果发现某个元素比例不对，先查它是不是漏转了 rem，再查是不是被某个固定 px 的父容器限制了宽度。这个排查顺序能快速定位大部分适配问题。

6.3 常见问题的快速对照

这张表是我自己排查时常用的对照，大部分适配问题都能归到这几类里。真正难缠的是那种"只在某台特定机型上出问题"的情况，那往往不是 rem 逻辑本身的问题，而是该机型浏览器对某个 CSS 属性的解析有偏差，需要单独做兼容处理。

6.4 文档与团队约定

最后一点容易被忽略但很重要：把基准关系、份数、转换规则、例外情况（哪些用 px、哪些用 rem）写进团队的前端规范文档。适配方案本身不复杂，复杂的是多人协作时各自理解不一致。我见过项目里两个人一个按 75 换算、一个按 37.5 换算，合并代码后页面一半正常一半错位，排查成本极高。约定写清楚，比任何技术方案都管用。

我个人在实际操作中的体会是，rem 这套方案的价值不在于它多先进，而在于它足够简单、足够统一。它把移动端适配从"每个元素单独调"变成了"调一个根字号，全局跟着走"。真正花时间的从来不是写那几行 JS，而是把基准约定、例外规则、高清屏补丁这些边角料处理干净。把这些细节提前想清楚，后面改需求、加页面的时候会省下大量返工。