第一次写 UniApp 项目的时候我心里一直打鼓设计稿上清清楚楚标着 750px那我是不是应该写成 750rpx换成逻辑分辨率只有 375px 的手机这东西不会直接缩成一半吧。后面我又在论坛里看到有人说 rpx 就是 rem 的马甲还有人言之凿凿说 rpx 是小程序的 rem搞得我更迷糊了。这问题其实特别典型大部分刚接触跨端开发的人都会卡在这一步。今天这篇文章我就把 rpx 的来龙去脉、换算逻辑、和 rem 的本质差异全部说清楚顺便把我自己在实际项目里踩过的坑一并交代。1. rpx 是什么一套设计稿宽度即代码数值的跨端单位1.1 我最初对 rpx 的误解先说说大多数人的直觉。很多人第一次看到 rpx第一反应是这是不是 responsive pixel响应式像素。然后打开开发者工具在 iPhone 逻辑宽度 375px 的模拟器上量一下发现 750rpx 刚好铺满整个屏幕于是得出一个粗浅结论rpx 大概是把屏幕宽度当成 750 来用的单位。这个理解前半段是对的但后半段容易跑偏。更常见的误区是有人把 rpx 当成一种px 的自动乘除工具觉得它的作用和 rem 一模一样只是换个名字。等你真的在平板上跑一下或者把系统字体调大就会发现这俩根本不是一回事。rpx 的本质是一套按屏幕宽度等比缩放的度量系统而 rem 的本质是围绕根元素字号做相对缩放两者的触发机制和适用边界差异非常大。1.2 rpx 的官方约定屏幕宽度拆成 750 份rpx 的规则可以用一句话讲完无论设备屏幕有多宽都把它当作 750 等份每一份就是 1rpx。举个例子假设一台手机的逻辑分辨率是 375px那屏幕宽度被分成 750 份之后1rpx 就等于 0.5px。如果一台安卓机逻辑分辨率是 412px1rpx 就等于 412 / 750 ≈ 0.549px。如果 iPad 的逻辑宽度是 768px1rpx 就等于 768 / 750 ≈ 1.024px。也就是说rpx 不是一个固定长度它是一个会根据屏幕宽度动态变化的相对长度单位。正因为这个特性你在 750px 宽的设计稿里量到的尺寸可以直接把数值抄到代码里设计稿上按钮宽度是 200px你写 200rpx窄屏上会自动变小宽屏上会自动变大最终保证这个按钮在屏幕上占的视觉比例是一致的。1.3 为什么偏偏是 750而不是 375 或 100这个 750 不是随便拍脑袋定的。早年移动端页面的主流设计稿宽度就是 750px原因是那个时期的主流机型逻辑分辨率通常为 375px而物理像素是它的 2 倍也就是 750px。设计师为了在高清屏幕上出图默认会按 2 倍尺寸设计于是 750px 成了事实上的设计稿标准。如果基准定成 375那设计稿里的数值还得手动除以 2显然不方便。定成 750 的聪明之处在于它让设计稿 px 数值与代码 rpx 数值直接一一对应设计师和前端之间的沟通成本瞬间降低。你可能还会问为什么不学 vw把屏幕宽度定成 100 份那样的话1rpx 相当于 0.1333vw也能做等比缩放。但它存在一个现实问题设计稿上 100px 的按钮你要先换算成 100 / 750 0.1333再乘以 100vw写起来不如直接写 100rpx 来得直观。所以 750 这个数字本质上是设计习惯与换算成本之间平衡出来的结果。2. rpx 的缩放原理和 vw 同源但不是一回事2.1 换算公式与手算实例rpx 在代码层面最终会被编译成真实的 px。它的计算公式可以写成1rpx 屏幕逻辑宽度px/ 750反过来如果你想知道某个元素在目标设备上到底占多少像素实际像素 rpx 数值 × 屏幕逻辑宽度 / 750举个实际例子。设计稿宽度 750px里面有一个卡片宽度标注 600px 高 300px。在逻辑宽度 375px 的手机上卡片实际宽 600 × 375 / 750 300px卡片实际高 300 × 375 / 750 150px正好占屏宽的五分之四左右和设计稿比例一致。换到逻辑宽度 412px 的手机上卡片实际宽 600 × 412 / 750 329.6px卡片实际高 300 × 412 / 750 164.8px视觉占比依然接近五分之四。这就是 rpx 的核心价值它保证的是元素占屏幕宽度的比例而不是一个绝对像素值。2.2 它和 vw、vh 的关系从数学角度讲rpx 和 vw 几乎是同一种东西。1vw 等于屏幕宽度的 1%也就是屏幕宽度除以 1001rpx 等于屏幕宽度的 1/750。所以1rpx 100vw / 750 0.1333vw1vw 750rpx / 100 7.5rpx也就是说如果你愿意完全可以用 vw 替代 rpx无非是多做一次换算。UniApp 在 H5 端和小程序端都支持 vw理论上你写 vw 也能实现等比缩放。但 rpx 的优势在于它已经帮你把设计稿 750 基准这件事固化了少一层心算。还有一个细节vw 是严格按视口宽度来计算的而 rpx 在部分端上会受容器或根环境的影响不过绝大多数场景下两者表现非常接近。2.3 高度用 rpx 时的隐藏问题rpx 的等比缩放只依赖屏幕宽度不依赖屏幕高度。这意味着你用 rpx 设置元素高度时这个高度也是按屏幕宽度的缩放系数来换算的而不是按屏幕高度。举例来说设计稿里有个弹窗高 900rpx在 375px 宽、667px 高的竖屏手机上它实际高 900 × 375 / 750 450px占屏高约 67.5%。但在横屏状态下假设逻辑宽度变成 667px那同一个弹窗的高变成 900 × 667 / 750 800.4px几乎充满整屏。问题就来了同样的 rpx 值横屏时高度暴涨弹窗大概率溢出。这不是 bug而是 rpx 的定位造成的它只管宽度方向上的比例高度方向只是被宽度牵连。所以如果你要做一个高度敏感的布局比如一屏内展示一个半屏的列表或者横屏适配强烈建议高度方向混用 vh、百分比或者计算属性而不是所有尺寸无脑 rpx。3. 和 rem 硬碰硬差的不只是基准值3.1 rem 到底怎么工作rem 是 CSS 里非常经典的单位全称 root em意思是相对根元素字号。它的换算极其简单如果根元素 html 的字号是 16px那么 1rem 就等于 16px2rem 等于 32px。默认情况下根字号是浏览器自己设定的通常是 16px。很多人做移动端适配时用 JS 根据屏幕宽度去修改根字号例如把屏幕宽度 375px 的根字号设成 37.5px然后把设计稿里的 100px 写成 100rem。注意这里有个容易混淆的点在这种方案里1rem 不是固定等于 1px而是相当于是设计稿像素的 1/10因为 1rem 37.5px 屏幕宽度的 1/10。这是 rem 适配的本质先定义一个缩放基准再把所有尺寸都表示成这个基准的倍数。3.2 一张表看清 rpx 与 rem 的差异我用一个表格总结一下这样对比最直观对比维度rpxrem基准长度屏幕宽度的 1/750根元素字号的 1 倍是否随屏幕宽度自动缩放是框架内置否需要 JS 修改根字号才会缩放默认行为天然等比缩放初始固定相当于 px 的别名依赖外部脚本不依赖通常依赖动态根字号脚本对系统字体缩放的感知不感知感知因为根字号可能被系统调节典型适用场景布局尺寸、间距、圆角文本层级、可访问性、固定比例在 UniApp 中的可用性内置支持支持但需要自己管理缩放看完这张表就能发现rpx 和 rem 并不是同一种思想的两版实现而是两个维度的东西一个是按屏宽等比缩放另一个是按根字号等比缩放。二者只有在同时动态修改根字号这个前提成立时表面行为才会相似。3.3 同一个页面在三种单位下的实际表现假设设计稿宽 750px里面有一个按钮宽 200px、高 80px、文字 28px。现在把它分别用 px、rpx、rem 写出来在屏幕宽度 375px 的设备上测试如果用 px按钮宽 200px视觉比例是 200 / 375 ≈ 53%。换到 412px 屏上按钮还是 200px视觉比例变成 48.5%。这就是固定像素的问题它不随屏幕变化看上去会越来越小。如果用 rpx按钮宽 200rpx375px 屏上实际 100px412px 屏上实际 109.87px视觉比例稳定在 26.7% 左右。这是等比缩放的效果。如果用 rem并且你不改根字号那 1rem 16px按钮 200rem 等于 3200px直接爆屏。所以 rem 方案必须配合脚本把根字号设为屏幕宽度的某个百分比比如 375 屏根字号设 37.5px按钮 200rem 依然爆屏。这说明 rem 的缩放系数完全由你决定它不像 rpx 那样把750 基准固化进框架里。3.4 rem 存在的自主缩放优势系统字号适配既然 rpx 这么方便为什么还会有人坚持用 rem最核心的原因是无障碍和系统字号适配。用户可以在系统设置里调大字体如果网页的根元素字号发生变化使用 rem 的文本会跟着变大而使用 rpx 的文本不会因为它只认屏宽不认字号。举个例子一个资讯类 App正文用 32rpx在 375px 屏上等于 16px阅读刚好。用户把系统大字模式打开后32rpx 依然等于 16px没有任何变化对老花眼用户很不友好。但如果正文用 1rem根字号从 16px 变成 24px 时正文也跟着变成 24px体验会好很多。所以我现在的习惯是正文文本避免使用 rpx要么 px要么 rem至少给系统字号适配留一条路。4. UniApp 里用 rpx真正的坑都藏在这些地方4.1 设计稿不是 750换算公式别记错rpx 默认的隐含前提是设计稿宽度 750px。可现实中设计稿可能是 375px、1242px甚至 1080px。如果设计稿宽度不是 750所有标注都要按比例换算rpx 数值 设计稿标注值 × 750 / 设计稿宽度比如设计稿宽 375px标注宽度 200px换算成 rpx 就是 200 × 750 / 375 400rpx。设计稿宽 1242px标注宽度 621px换算成 rpx 就是 621 × 750 / 1242 375rpx。绝大多数情况下你先确认设计稿的宽度再去做批量换算顺手把团队的设计规范固定成统一出 750 宽度的稿子能省掉大量重复劳动。4.2 大屏和平板的无限放大问题rpx 等比缩放看起来很美好但有一个副作用屏幕越宽所有东西越大。在手机上750 基准保证比例协调换到平板768px 逻辑宽度下1rpx 约等于 1.024px一个小按钮的宽高全都放大接近一倍整个页面看起来像老年模式。我做过一个跨端项目产品要求在平板上实现两栏布局而不是手机上的单栏全宽按钮结果因为整个页面全部用 rpx平板端按钮还是全宽、超大。后来解决方案很简单在平板宽度断点内不再用 rpx 做容器宽度改用固定最大宽度或百分比布局只有手机端才保留 rpx 的等比逻辑。如果你不想做这么复杂的适配至少给根容器加一个 max-width比如 500px防止内容在平板上被无脑放大。4.3 文本、边框、阴影不适合无脑 rpx文本用 rpx 还有一个隐藏问题字号的可读性并不完全跟屏宽成正比。在 375px 屏上24rpx 等于 12px能看清在 412px 屏上24rpx 等于 13.18px差异不大但在平板 768px 屏上24rpx 等于 24.58px标题像广告牌正文也喧宾夺主。文本尺寸更适合跟随用户偏好字号和阅读密度而不是粗暴地跟着屏宽等比放大。细边框也一样。你写 1rpx 边框在 375px 屏上等于 0.5px恰好能呈现细线效果在 412px 屏上等于 0.55px还行但在某些屏幕上会出现渲染成 0 或虚化的情况。更稳妥的做法是从一开始就明确需要小于 1px 的细线用 px 直接写 1px或者用 transform: scale(0.5) 模拟而不是依赖 rpx 的浮点换算。阴影同理box-shadow 的模糊半径用 rpx 很容易在不同端产生奇怪的模糊程度建议大数值固定用 px 或 rem。4.4 原生组件和动态样式的兼容盲区UniApp 是一个跨端框架会编译到 H5、小程序、App 等多个平台。不同的端对 rpx 的解析存在细微差异尤其是在原生组件内部。比如原生地图、视频播放器、输入法的弹层它们并不是普通 WebView 里的 DOM 元素rpx 在它们内部可能不会按预期缩放甚至完全不生效。另外动态绑定样式时也要小心。你在 JavaScript 里拼 style 字符串给一个元素动态设置 width如果拼的是200rpx在大多数端没问题但如果你需要根据运行时数据计算宽度比如item.width * 0.72 rpx先在脑袋里过一遍算出来的值是不是你想让它在屏幕上呈现的比例。rpx 的缩放是在渲染时发生的所以运行时计算同样适用但一定要保证计算基准一致别一时顺手把设计稿 px 和运行时代码里的 px 混用。4.5 rpx 遇上条件编译和组件隔离时的注意点UniApp 支持条件编译你可以针对不同平台写不同的样式。比如在小程序端用 rpx在 App 端改用 px实现上没问题但要注意维护成本。我见过一个项目条件编译里散落着三种单位后来设计师改一个间距前端要改五个文件还经常漏掉某个平台。组件隔离也是个值得注意的点。在 Vue 单文件组件里style 加了 scoped 之后rpx 的换算不受影响这点不用担心。但如果你用了第三方 UI 库它们的样式可能默认用 px 或 rem和你的 rpx 混在一起后视觉比例会突然不对。排查方式很简单浏览器开发者工具里找到对应元素看 Computed 样式里最终算出的 px 值再对照你预期的比例就能判断是哪个单位在捣乱。5. 我的选型方法把 rpx、rem、px 当作工具而非宿命5.1 以是否该随屏幕等比来决策我用 rpx 的标准很简单这个属性需不需要跟着屏宽等比缩放。如果需要比如按钮宽度、卡片间距、栅格留白就用 rpx如果不需要比如文本字号、细边框、固定弹窗最大高度就用 px 或 rem。这个判断标准比统一全用 rpx或者彻底抛弃 rpx靠谱得多。以我自己做的一个偏内容型项目为例.card { width: 690rpx; /* 卡片宽度跟随屏宽 */ padding: 24rpx 32rpx; /* 内边距跟随屏宽 */ border-radius: 24rpx; /* 圆角跟随屏宽 */ } .card__title { font-size: 32px; /* 正文标题固定不随屏宽暴涨 */ line-height: 1.5; } .divider { height: 1px; /* 细线用 px 保证渲染稳定 */ background: #e5e5e5; }这套规则的好处是团队成员不用每次写样式都纠结半天问一句这个值跟随屏宽吗答案就出来了。对应的单位的使用也规整了。5.2 用 CSS 变量做一套设计代币避免单位散落各处比单位更值得管理的是设计数值本身。我建议在项目里用 CSS 变量把设计规范沉淀成一套 token而不是让开发者在代码里到处写24rpx、32rpx、40px。比如:root { --space-xs: 8rpx; --space-sm: 16rpx; --space-md: 24rpx; --space-lg: 40rpx; --radius-sm: 8rpx; --radius-md: 16rpx; --font-body: 28px; --font-title: 36px; }业务组件里只引用这些变量.card { padding: var(--space-md); border-radius: var(--radius-md); }这样做有几个直接好处一是换单位时只改变量定义这一处不用全局搜索替换二是设计师改间距时前端改一行页面所有地方跟着变三是新成员入职后看到变量名就知道该用哪个值不会凭感觉造一个大概是 26rpx的新尺寸出来。5.3 一个简单的落地规范示例我在团队里定的规范大概是这样的你可以直接抄去改成适合自己项目的版本场景推荐单位原因栅格、卡片、按钮等布局宽度rpx需要跟随屏宽等比缩放间距、内边距、外边距rpx视觉节奏需要等比圆角、阴影模糊、图标尺寸rpx 为主阴影用 px阴影模糊在部分端渲染不稳定正文、标题、说明文字px 或 rem保证可读性和系统字号适配小于 1px 的细线边框px 配合 transform/hairline防止浮点渲染虚化弹窗最大高度、整屏高度相关vh 或 calcrpx 不感知屏幕高度横向界场景会出问题这份规范不是死规矩它更多起到防呆作用。每次代码评审重点看两类问题一是有没有把文本字号写成 rpx二是有没有把弹窗高度写成 rpx。看过几轮之后团队就形成条件反射了。5.4 这套规范落地后踩到的一个实际反馈有一次设计师给了一套新的视觉稿按钮宽度从 200rpx 改成 180rpx卡片间距从 24rpx 改成 16rpx。因为有设计代币我只改了变量文件里几个值全站样式自动更新。但紧接着 QA 在平板上提了个 bug卡片文字在平板上显得略小。我一看卡片标题用的是 32px在手机上 32px 看起来和谐平板上其实应该更大一些才对。这个问题的根源恰恰是我用了 px 保护文本却丢掉了等比放大。最后我调整了策略标题这类相对重要的文本改用clamp(24px, 4vw, 40px)这样的表达式让它既不像 rpx 那样线性放大也不会在平板上纹丝不动。这就是单位选型的取舍艺术——纯 rpx 解决不了所有问题纯 px 也不行关键是分清当前需求更看重哪一个维度。6. 最后分享一点使用习惯如果你问我个人最推荐的开局方式我会说新建项目时默认布局单位全用 rpx文本字号全用 px然后跟着真实设备去调而不是一开始就堆一套复杂的 JS 根字号适配脚本。先把基础跑通等真的遇到平板适配、系统大字、横屏场景再切换到对应的混合方案。我在实际项目里发现绝大多数页面 80% 的单值用 rpx 就够了剩下 20% 的边界情况用 px、rem、vh 单独处理代价远比全局改造小。还有一个小技巧在真机上调试时多看开发者工具里 Computed 样式那一栏它会把 rpx 换算后的实际 px 值告诉你。对比一下设计稿标注的比例你就知道当前单位设置是否符合预期。毕竟设计稿是静态的rpx 换算却是动态的培养这种用比例思考而不是用标注思考的习惯才是跨端开发里真正值钱的经验。