UniApp中rpx与rem深度对比：原理、换算与迁移实战

做UniApp开发的朋友，十有八九都会在官方文档或者同事的代码里碰到 rpx 这个东西。尤其当你之前做Web开发，习惯用 rem 控制字号和间距，第一次看到 rpx 的时候很难不想：这俩是不是一回事？能不能直接替换？哪个更适合做跨端适配？

我现在给的结论先放这儿：rpx 是 UniApp 和微信小程序里特有的一种“动态单位”，它和 rem 有相似的部分，但底层逻辑完全不同。如果你只是把 rem 换成 rpx，而不理解它的基准是什么，那么在小屏手机上可能没什么感觉，一旦跑到平板或者横屏场景，页面分分钟“放飞自我”。

本篇我就以实际开发视角，把 rpx 的定义、换算原理、与 rem 的差异、迁移技巧和踩坑实录一次性讲透。适合刚接触 UniApp 的前端新人，也适合打算把 H5 项目改成小程序、或者统一多端样式的老手，下面直接上干货。

1. 先搞清楚 rpx 的身世：它到底凭什么自动适配

1.1 从设计稿到屏幕宽度的基准

rpx 的全称是 responsive pixel，我习惯叫它“响应式像素”。它最基本的规则是所有屏幕的宽度都被视为 750rpx。注意，这里说的是“逻辑上”，不是物理上，意思是无论手机实际宽度是 375 物理像素、390 物理像素还是 414 物理像素，在全屏竖屏状态下，rpx 的基准宽度永远是 750。

这就有个特别直接的好处：设计师给一套 750 宽的设计稿，也就是常见的 iPhone 6/7/8 Plus 那一代设计稿宽度，你几乎不需要做额外换算，设计稿上标的 100px，代码里直接写 100rpx，尺寸就对上感觉了。如果用 rem，你还得先把设计稿按根字号折算，或者自己写一个基于屏幕宽度的工具函数，麻烦不少。

从原理上说，rpx 的换算公式是：1rpx = 当前屏幕宽度 / 750。比如屏幕实际宽度是 375px，那么 1rpx = 0.5px；屏幕宽度是 390px，那么 1rpx = 0.52px。这样写出来的样式，在不同宽度的手机上会自动按“屏宽占比”缩放，而不是像 px 那样固定死。

1.2 rpx 的换算机制和实现细节

如果你去看 UniApp 编译后的产物，或者在小程序开发者工具里看样式，会发现 rpx 并不是浏览器原生认识的单位。UniApp 的编译器会在打包阶段把它转换成可执行的 CSS 类，最终由小程序运行时去计算。

有些同学问：是不是 rpx 也是用 JS 动态算然后设置根元素？其实不是。小程序端的 rpx 是运行环境底层直接支持的，渲染层在排版时会根据屏幕宽度做实时计算；在 H5 端，UniApp 会通过内置的 postcss 插件把 rpx 转换成基于视口宽度的 CSS 变量或者 vw 换算，保证多端表现一致。

这里我补充一个经常被忽略的点：rpx 的基准 750 并不等于手机屏幕一定是 750 物理像素。它只是一个约定俗成的设计基准，选 750 是因为主流设计稿大都来自这个宽度。如果你团队的规范用的是 375 设计稿，也没关系，直接按 2 倍关系换算就行，或者让设计同学出一版 750 的标注，效率会高很多。

1.3 为什么说 rpx 更像“百分比”而不是“像素”

理解了公式后，你会发现 rpx 本质上是一种“等比缩放”。100rpx 固定在屏幕宽度的 100/750 = 13.33%。用百分比的思路去理解它，比把它当成像素更准确。

例如一个按钮宽度是 300rpx，那它在所有屏幕上都会占屏幕宽度的 40%。这种特性在列表卡片、栅格布局上尤其好用，因为卡片之间的间距和卡片宽度都是以屏幕宽度为参照系，天然就能做到“一套样式，多端匹配”。而 px 单位做不到这一点，rem 单位只能通过根元素间接影响，没法直接跟屏幕宽度绑定。

也正因为 rpx 这种强缩放属性，使用的时候要小心：如果你在同一个容器里混用 rpx 和固定 px，有可能会出现容器比内容小、文本溢出的问题，这个我在后面实操部分会详细讲。

2. 和 rem 硬碰硬：同一个页面，两者差在哪

2.1 rem 的“锚点”是根字号，rpx 的“锚点”是屏宽

rem 的全称是 root em，它只相对于根元素的 font-size 计算。比如你给 html 设置 font-size: 16px，那么 1rem 就是 16px；如果设置 font-size: 20px，那么 1rem 就是 20px。

所以在 H5 适配中，常见的做法是用 JS 动态计算根字号。比如把屏宽分成 10 份，375px 宽时根字号设成 37.5px，然后设计稿里 100px 就写成 100/37.5 ≈ 2.667rem。这样宽度变化时字体和间距会跟着根字号一起变，达到“弹性”的效果。

rpx 完全绕开了这个步骤。它不需要你操作 html 根元素，也不依赖 font-size，它的锚点是屏幕宽度本身。一个直接后果：rpx 在 UniApp 的任意一个页面里，表现都一样，不会因为你改了某个组件的 font-size 而影响其他元素的尺寸。这一点在组件化开发里特别友好，因为组件内的局部 fontSize 设置不会污染全局布局。

2.2 响应式表现：谁更跟手，谁更可控

做个小对比。假设有两个盒子，一个宽度为 3rem，另一个宽度为 300rpx，都在 375px 宽的屏幕上显示。如果根字号是 37.5px，3rem = 112.5px；300rpx = 375px * 0.4 = 150px。二者没有任何直接换算关系，完全是两套体系。

再假设屏幕宽度变成 768px（iPad 竖屏）。根字号如果还按“屏幕宽度/10”动态计算，就是 76.8px，那么 3rem = 230.4px；而 300rpx = 768px * 0.4 = 307.2px。两者都会变大，但比例逻辑不同：rem 受根字号影响，而根字号的具体值取决于你的 JS 策略；rpx 则永远是“三等分屏宽的 40%”，没有中间商。

所以如果你的适配策略是“页面元素相对屏幕宽度等比缩放”，rpx 更跟手，因为不用维护那层根字号映射。如果你的策略是“全局字号跟随根字号统一缩放，间距使用 rem 做比例控制”，在纯 H5 项目里 rem 也很可靠，但到了 UniApp 里会增加维护成本，因为多端环境下根元素差异比较难统一。

2.3 对比表格和场景选择

如果你主要是做 UniApp 的小程序/H5 双端输出，我建议主力单位用 rpx；如果某个页面只是嵌在 App 里的 WebView，且不依赖 UniApp 编译，那还是可以用 rem，毕竟浏览器生态里 rem 更通用。

3. 项目里的实操：怎么换算、怎么迁移、怎么混用

3.1 rpx 换算公式和设计稿标注的快速心法

真到写代码的时候，最核心的一件事就是拿到设计稿后快速换算。按 750 基准设计稿，直接写同数值 rpx，这是最快的方式。比如设计稿上卡片圆角是 12px，你不用算，直接写成 12rpx；间距 20px，写成 20rpx。

如果是 375 基准的设计稿，我自己的心法是“乘以 2”。因为 375 设计稿的宽度正好是 750 逻辑宽度的二分之一，所以设计稿标 20px，代码写 40rpx。120px 宽的元素，写 240rpx。这个方法在第一次快速搭建页面时特别实用，不需要逐个比例推算。

如果你拿到的视频号、小程序压缩包里有别人写好的 rem 代码，需要换算成 rpx，那就要先看他们的根字号策略。比如某个项目用“屏宽/10”作为根字号，设计稿 20px = 2rem。在 375 屏宽下 2rem = 75px，要转成 375 基准的 rpx 就是 75*2=150rpx。也就是说，要先把 rem 还原成 px，再把 px 换算成对应设计稿基准的 rpx，两步走，别直接拿 rem 值乘以某个固定系数，那样必错。

3.2 从 rem 迁移到 rpx 的步骤与代码兜底

这里给一个我在模拟项目 X 中实际操作过的迁移流程。那个项目原本是一套 H5 模板，大量使用 rem 做间距和字号。后来切入 UniApp 后，我决定把核心组件全部迁到 rpx，保留极少量 rem 做富文本渲染。

第一步：清掉全局根字号动态设置。UniApp 页面里不需要再监听 resize 去改 html font-size，如果是从 H5 复制的代码，首先要删除这段脚本，否则根字号会干扰 rem 和 rpx 混用的结果。

第二步：批量替换。如果项目里有 750 基准设计稿，直接把样式文件里的所有 px 手写值改成 rpx。如果是从 rem 迁移，先还原成 px。常见的做法是：在 VS Code 里用正则做一轮替换，比如(\d+)rem替换成($1 * 75)rpx，但要注意这只是快速预替换，之后必须人工核对每一个值，因为不同根字号策略算出来的结果不一样。别指望一个正则解决所有问题。

第三步：处理边界单位。字体大小、边框宽度、阴影扩散范围这一类“非等比缩放”属性，我强烈建议保留 px，或者使用rpx但配合 CSS 变量固定关键值。因为字体的等比缩放容易导致字号在 320 宽小屏上偏小、在大屏上偏大的观感问题。

我实际的经验是，rpx 迁移后第一遍跑，必然有视觉偏差，不要慌。重点检查列表项高度、按钮内边距、图片宽度这三类高频属性，多数偏差都出在这三类。反复调两个页面之后，你就能建立经验，哪些地方直接写死 px 反而更省心。

3.3 字体、边框等特殊场景的处理

很多人刚开始用 rpx 的时候，会用 rpx 写 font-size，这是最常见的坑之一。因为字体不是一个纯长度单位，它需要考虑阅读体验和系统默认值。如果 375 屏宽下 14px 字体，写成 28rpx，那在 414 宽的手机上就会渲染成 28 * 414/750 ≈ 15.45px，其实还好。但在平板上可能会变成 20px+，标题还好，正文就很夸张了。

所以我给出的经验规则是：

• 正文、说明文字：使用 px 或固定 rpx 范围，避免过大跳变。
• 标题、卡片内大数字：可以用 rpx，让它跟随屏幕宽度有一定缩放，但设置 max-font-size 策略，或者用媒体查询兜底。
• 边框 width：建议用 px，因为 1rpx 在小屏上可能渲染不足一个物理像素，部分安卓机偶发“边框消失”的诡异问题。
• 阴影和圆角：圆角可以用 rpx 保持视觉协调，阴影模糊半径建议 px，扩散半径跟着 rpx 走问题不大。

3.4 有没有必要混合使用

我的答案是：混合使用不仅正常，而且推荐。完全只用 rpx 会在大屏上产生很多失控场景，完全只用 px 又会失去适配能力。所以我自己的项目里通常这样规定：

• 布局尺寸、间距、宽高、圆角：用 rpx。
• 字体大小、边框宽度、阴影：用 px。
• 涉及第三方富文本或者 WebView 的 HTML：内部保留 rem 或者 px，因为 rpx 在未经编译的文本内容里不会生效。

这种混合策略并不是“和稀泥”，而是利用了不同单位的特性。rpx 负责“结构弹性”，px 负责“细节稳定”。比如一个卡片，宽度 680rpx，内边距 20rpx，标题 18px，描述 14px，边框 1px，这样在小屏上卡片比例和间距依然舒服，字体也不会过度缩放，边缘依旧清晰。

4. 实战复盘：遇到这些坑，我最后怎么绕过去的

4.1 边框线和阴影在 rpx 下的显示差异

有一次我在某图像处理 Demo 的详情页里给按钮写边框，宽度用了 2rpx，结果在 iOS 的 Retina 屏上看着正常，在部分安卓机上一会儿粗一会儿细，还有的直接显示不出来。后来排查发现是渲染精度问题，rpx 在换算后有小数像素，边框宽度低于物理像素阈值时被四舍五入成 0。

后来我把所有 border 的宽度统一改成 1px，同时配合transform: scale处理需要更细线条的场景，问题就消失了。这里也建议做跨端时，把“需要边界清晰”的元素用 view 包一层，左右边框用伪元素模拟，并且设置媒体查询，确保在各端表现一致。

4.2 大屏和平板：rpx 的放大效应

rpx 会随屏宽放大，这在竖屏手机上很舒服，但一旦跑到平板或横屏场景，就会出现“布局被撑得很大”的情况。比如 iPad 竖屏宽度 768px，一个按钮宽度 600rpx，就直接变成 768 * 0.8 = 614px，接近全屏宽，视觉上很夸张。

遇到这种情况，我用的解决方案是：给外层页面加一个最大宽度限制，比如max-width: 750rpx; margin: 0 auto;。这样一来，在大屏上 rpx 虽然还在换算，但容器宽度被限制在 750rpx 以内，按钮不会无限放大，页面中心和两侧留白也算好看。还有一种是配合媒体查询，在min-width超过某个阈值后，改用 px 固定布局，但这种方式维护成本稍高，适合管理后台型页面。

4.3 动态改变屏幕方向或横竖屏时的表现

UniApp 页面默认支持屏幕旋转时，rpx 会随新的屏幕宽度重新计算，这个机制在竖屏切横屏后会立刻生效。听起来很智能，但实际有个问题：如果你在样式中用 rpx 写了一个正方形的头像，宽 200rpx、高 200rpx，横屏后宽度变大，高度也变大，但如果你的图片资源是固定像素的，它可能被拉伸变形。

我的处理办法是：关键视觉元素尽量使用aspect-ratio控制比例，或者使用固定宽高 +object-fit: cover，让图片内容自适应裁剪，避免依赖 rpx 双方向同时等比缩放。还有一点，如果页面里有横向滚动列表，rpx 会随着滚动容器宽度变化，但只滚动一个方向不会改变屏宽，所以不会有问题。真正需要注意的是 split-view 或者自定义分栏布局，这种情况下 rpx 的基准不会自动适配当前分栏宽度，因为它拿的是整个窗口宽度。

4.4 rpx 与 CSS 变量的结合

早期写 Uniapp 时，我经常为“设计稿换主题色/换间距体系”烦恼。后来我发现 rpx 也可以配合 CSS 变量使用，效果很好。比如在page级别定义：

page { --gap-base: 30rpx; --color-primary: #4a7cf7; }

然后在组件里写：

.card { padding: var(--gap-base); background: var(--color-primary); }

这样做的好处是，换主题时只需要改变量定义，rpx 的实际换算依旧由 UniApp 处理。对于需要频繁改版的项目，可以省掉很多全局替换工作量。

不过有一个坑，CSS 变量在小程序端的支持并不如 H5 那么完整。部分低版本安卓微信小程序对 CSS 变量的继承和动态更新支持有 bug，尤其是var()用在伪元素上时偶尔失效。稳妥起见，我会把跨端组件的核心布局尺寸直接写 rpx，把主题色和次要间距用 CSS 变量，既保住功能，又兼顾维护性。

结尾

说几个个人习惯上的建议：如果你刚开始从 Web 转到 UniApp，先不要急着把全项目所有单位都改成 rpx，那样会放大你对手写设计稿换算的陌生感。不如先拿一个列表页和一个详情页做试验，把布局类尺寸切到 rpx，把字体和边框留在 px，多跑几台机器看效果，慢慢你就会摸到“哪些属性该用 rpx、哪些该用 px”的边界。

我自己用下来最大的体会是，rpx 不是一个完美的单位，它的自动等比缩放是一把双刃剑。用对了，可以省掉大量适配代码；用错了，会让你在调试大屏和横屏时怀疑人生。关键是把它当成一种“以屏宽为参照系的工具”，而不是通用长度单位。这样再回过头去和 rem 做对比，思路会清爽很多。