牧宇的Blog

工程师的笔记

0%

小程序组件库该用rpx还是px？

发表于 分类于

一、问题背景：组件库用 px，业务开发用 rpx

1.1 现状冲突

目前小程序的开发领域有一个奇怪的现象：

  • 组件库：Vant、Uni-UI 等主流组件库的样式表中，width: 100px 随处可见
  • 业务代码：业务前端清一色使用 width: 200rpx，开发者对 rpx 趋之若鹜

这就引出一个矛盾点：当开发者引入一个 px 单位的按钮组件时，必须手动覆盖样式或做单位转换：

1
2
3
4
/* 业务代码中强行适配 */
.van-button {
  width: 200rpx!important; /* 破坏组件库封装性 */
}

1.2 为什么组件库坚持 px？

历史原因：2017 年微信小程序刚推出时，rpx 的渲染机制存在 BUG（如 iOS Retina 屏模糊），早期组件库被迫选择 px。
跨端隐患：部分跨端框架（如 Taro）需用 px 兼容 H5 和 APP，直接使用 rpx 会导致多端样式混乱。
稳定性担忧：px 在折叠屏、Pad 等设备上表现更可控，rpx 的全局缩放可能导致组件错位。

二、业务开发为何偏爱 rpx？

2.1 效率碾压式优势

假设设计师提供 750px 宽度的设计稿：

  • rpx 方案：直接按 1:1 映射，200px 的元素写作 200rpx
  • px + 响应式方案：需计算百分比、设置断点、处理多端差异

实际对比：开发一个商品列表页：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
/* rpx 方案 */
.item {
  width: 350rpx; 
  margin: 20rpx;
}

/* px + 响应式方案 */
.item {
  width: 175px;
  margin: 10px;
}
@media (max-width: 375px) {
  .item { width: 150px; }
}
/* 还要考虑华为折叠屏、iPad等设备... */

2.2 设计协作的天然优势

当设计稿标注为 750px 时：

  • 开发者：无需换算，设计稿标注值 = rpx 值
  • 设计师：不需要学习 vw/rem 等复杂单位

三、化解矛盾的工程方案

3.1 方案一：组件库提供 rpx 版本

实现原理：通过 CSS 变量动态切换单位

1
2
3
4
5
6
7
8
9
/* 组件库源码 */
.van-button {
  width: var(--button-width, 100px); 
}

/* 业务代码注入变量 */
:root {
  --button-width: 200rpx; /* 一键切换为 rpx */
}

案例：京东 NutUI 小程序版支持 px/rpx 双模式，通过 npm run build:rpx 生成 rpx 版本。

3.2 方案二：构建工具自动转换

实现原理：用 PostCSS 插件批量转换组件库的 px → rpx

1
2
3
4
5
6
7
8
// postcss.config.js
module.exports = {
  plugins: {
    'postcss-px2rpx': {
      ratio: 2 // 1px = 2rpx（根据设计稿调整）
    }
  }
}

转换效果：

1
2
3
4
5
/* 输入：组件库源码 */
.van-button { width: 100px; }

/* 输出：转换后代码 */
.van-button { width: 200rpx; }

这部分做得比较好的是滴滴的小程序框架 Mpx，它内置了px到rpx的转换功能，并且支持选择性转换，开发者可以通过注释来标记不需要转换的px，大大提高了开发灵活性和效率。

四、选型建议：根据团队类型抉择

团队类型 推荐方案 原因
自研组件库 原生支持 rpx 掌控源码，无历史包袱
使用第三方组件库 方案二（构建工具转换） 无侵入、低成本适配

五、总结与展望

5.1 核心结论

  • 组件库可以选择 rpx
  • 工程化是破局关键：通过工具抹平单位差异，开发者不必二选一

让技术回归本质：单位的本质是提升效率而非制造对立。当工具链足够成熟时，开发者终将摆脱单位之争，专注创造业务价值。