企业官网建设流程全解析

1. 项目概述：为什么要把px自动转成rem

两年前我接手一个移动端H5项目，设计稿给的是750px宽的，要求在所有机型上都能完美还原。第一版我老老实实手动换算，每个尺寸都用计算器除以2，写样式时脑子里全是“这个按钮宽度是120px，除以2就是60rem，不对，是0.6rem？”。一个页面几十个组件，光换算就占了大量时间，还经常因为算错导致样式对不上设计稿。

后来我彻底想通了——这种事就该交给工具干。把CSS里所有px自动转成rem，构建时一步到位，手动干预越少越好。做完之后，整个团队的开发效率明显提升，设计稿还原度也从“大概对齐”变成了“像素级一致”。这个方案不仅适用移动端H5，也适用于需要适配多种屏幕尺寸的Web应用。

这篇内容适合谁看？如果你正在做移动端适配、需要严格还原设计稿、或者单纯不想再手动算rem，这篇文章能帮你少走弯路。我会把px自动转rem的完整方案、工具链配置、踩过的坑全部写清楚，照着操作就能跑起来。

1.1 这个方案解决的核心问题

移动端适配的本质问题是：设计稿只有一个尺寸，但用户的屏幕千差万别。如果你用px写死，手机宽度从320px到430px再到折叠屏的800多px，同一套样式在不同机器上要么太大要么太小，布局甚至直接错乱。

把px转成rem，相当于给所有元素赋予一个“相对比例”属性。每个元素的长宽、间距、字号，都以根元素的font-size为基准按比例缩放，屏幕宽度变了，整体布局同步缩放，设计稿的视觉比例就能在不同机型上保持。举一个生活化的例子：px就像用厘米做单位的纸质地图，地图有多大，尺寸就写多少；rem就像比例尺，你告诉系统“按当前屏幕的十分之一来算尺寸”，屏幕变大，所有东西等比放大，地图永远贴合屏幕。

不过单纯转换还不够，你还需要一套配套的适配策略——动态设置根font-size。这两个部分加起来，才算一套完整可用的移动端适配方案。

2. 核心原理：px、rem和根font-size的关系

在动手配置工具之前，先把基础概念彻底讲透，这样后面遇到问题才知道往哪个方向排查。很多人用rem好几年，问他“为什么是除以10而不是除以100”，他说不清，这就是隐患。

2.1 一个容易被忽略的单位换算逻辑

px是物理像素单位，数值固定，1px在任何设备上都是1px的显示尺寸。rem是相对单位，它相对于html元素的font-size。如果根font-size是16px（浏览器默认值），那1rem等于16px；如果你把根font-size设为37.5px，那1rem就等于37.5px。

所以把px转成rem，本质就是做一道除法：目标元素在设计稿上的px值，除以当前根font-size对应的px值，得到的就是rem数值。比如设计稿里有一个按钮宽度是150px，你的根font-size设成37.5px，换算结果就是4rem。页面加载时，根font-size会根据屏幕宽度动态调整，屏幕越宽数值越大，所有使用rem的按钮也跟着变大。

这里必须注意一个细节：不是所有px都应该转。边框、圆角、阴影这类视觉细节，如果也等比缩放，在小屏幕上会显得太粗或者太散，多数方案里都会配置“最小保留阈值”——如果元素尺寸小于这个值就不转换，依然使用px。以后面要讲的postcss-pxtorem为例，minPixelValue设置为2，小尺寸都跳过转换。这样既保证布局整体缩放，又不让细节变形。

2.2 为什么设计稿基准宽度选750px

移动端设计稿最主流的宽度是375px（iPhone的逻辑宽度）和750px（它的2倍图）。选750px有一个直接的好处：在这个基准下，视觉稿上给的px数值在2x屏幕上正好对应物理像素，切图、标注都比较直观。实际操作时，我们一般把根font-size设成设计稿宽度的十分之一——375的设计稿就设37.5px，750的设75px。

为什么是十分之一？因为rem计算时小数位太多会容易产生精度问题。750px设计稿，各个元素标出来的px值动辄上百，除以10之后是1-20之间的数字，既好读又不会被浏览器舍入误差影响。以75px为例，设计稿里左右边距是30px，转成rem就是0.4rem，计算过程简洁明了。如果除以100，会得到一堆熟悉又繁琐的0.3、0.15这样的小数，代码容易写错。

3. 实操环节：搭建px自动转rem的项目工作流

有了理论铺垫，现在说说我实际搭项目的完整过程。这套方案在Vue项目和纯静态页面里我都跑通过，下面按照从零到一的顺序带大家走一遍。

3.1 基础方案：lib-flexible加postcss-pxtorem

这组搭档是前几年的主流做法，到现在依然稳定可靠。lib-flexible负责动态设置根font-size，postcss-pxtorem负责构建时把px转成rem，两个插件各自干好一件事。

第一步，安装依赖：

npm install lib-flexible postcss-pxtorem --save

第二步，引入lib-flexible。在Vue项目的入口文件main.js里加入：

import 'lib-flexible'

lib-flexible的工作逻辑是：读取设备宽度，根据公式把根font-size算出来，并注入到html标签上。它默认的基准是设计稿宽度除以10。需要重点提醒的是：lib-flexible默认以375px为设计稿基准，但如果你的设计稿是750px，单靠它是不够的，需要在meta标签里做调整，或者直接改用自己写的适配方法。我在项目里通常直接用一个自写的适配脚本替代lib-flexible，后面3.2节会给出代码。

第三步，配置postcss-pxtorem。在项目根目录创建postcss.config.js：

module.exports = { plugins: { 'postcss-pxtorem': { rootValue: 37.5, propList: ['*'], selectorBlackList: ['.no-rem', '.ignore-rem'], minPixelValue: 2, exclude: /node_modules/i } } }

这几个参数的含义我逐个解释一下。rootValue是设计稿基准宽度对应的根font-size，375px的设计稿写37.5，750px的设计稿写75。propList是允许转换的属性列表，['*']表示所有属性都转。selectorBlackList指哪些选择器不转换，比如你有些第三方插件的样式不想被改动，加进去就行。minPixelValue是我们前面说的细节保留阈值，2px以下不转。exclude是排除目录，node_modules里的库文件一般不处理。

完成这三步，你在代码里写的所有px值，构建加载后都会自动变成对应的rem值。如果想在浏览器里确认转换是否成功，右键检查元素，样式里看到的是rem单位，说明配置已经生效。

3.2 自写适配脚本，代替lib-flexible

lib-flexible本身有维护者不再更新、项目体积等问题，我更推荐在项目里自己维护一个十几行的适配脚本。它是纯JavaScript逻辑，不依赖任何第三方库，可控性更强。

在src/utils目录下新建rem.js：

(function flexible() { var docEl = document.documentElement var dpr = window.devicePixelRatio || 1 function setBodyFontSize() { if (document.body) { document.body.style.fontSize = 12 * dpr + 'px' } else { document.addEventListener('DOMContentLoaded', setBodyFontSize) } } setBodyFontSize() function setRemUnit() { var rem = docEl.clientWidth / 10 docEl.style.fontSize = rem + 'px' } setRemUnit() window.addEventListener('resize', setRemUnit) window.addEventListener('pageshow', function(e) { if (e.persisted) { setRemUnit() } }) })()

这段代码的核心是setRemUnit函数：每次屏幕尺寸变化，都把根font-size重设为屏幕宽度的十分之一。配合postcss-pxtorem的rootValue（仍写37.5），就能保证任何宽度下页面按比例缩放。

引入方式也很简单，在main.js里直接import：

import './utils/rem.js'

从lib-flexible切到这个自写脚本后，我的项目少了依赖包袱，行为也完全可控。跟lib-flexible最大的差别是：lib-flexible还会根据devicePixelRatio做整个页面的缩放，这个自写脚本不主动改viewport和缩放比，避免了某些场景下字体发虚的问题。

3.3 各步骤里的核心参数计算过程

很多朋友配置完发现“有的px转了，有的没转”，多半是rootValue没配对。我详细讲一下这个参数该怎么推算。

假设设计稿是750px宽，你的目标基准是：在750px的屏幕上，根font-size设为75px。这时候一个在设计稿上宽150px的按钮转成rem就是2rem，接下来的适配就交给适配脚本。postcss-pxtorem里的rootValue，就要填和这个目标基准一致的数值，即75。如果你用的是375px设计稿，目标基准是37.5，rootValue就填37.5。

另一个需要协调的地方是：你自写或者引用的适配脚本，设置的根font-size数值，必须和rootValue保持一致的设计基准。否则出现的情况是：CSS转换用的基准是37.5pt，但运行时页面根font-size可能被设成75px，那所有尺寸都会放大一倍。这类错位问题在团队项目里真的出现过，查了半天才发现是两个基准不一样。

关于minPixelValue，我建议设成2-3。设计稿里小于等于1px的线条、分割线，转成rem之后在部分Android上可能会渲染不出来或者变成模糊的灰线。保留为px，多个设备上显示更稳定。

4. 常见问题与实战排查技巧

这套方案在常规的移动端页面里跑得很顺，但有几种特殊情况会让转换结果和设计稿有出入。这些问题我在项目里反复遇到过，整理成速查表，遇到直接对号入座。

4.1 字体大小怎么处理

最常被问到的就是：字体也要转成rem吗？文字在现代移动端页面里，主流做法是保持px或使用vw/vh。原因有二：一是中文字体在极小尺寸下渲染容易发虚，rem等比缩小时，某些机型上会出现字号小于12px的情况；二是从用户体验角度，小屏幕下文字过小是硬伤。

如果你希望所有属性都转，但在字体上不转，可以把propList中的font-size去掉：

propList: ['*', '!font-size']

如果你希望字体在大多数设备上按比例缩放但是不低于12px，那就用另一个插件postcss-px-to-viewport处理字号。不过说实话，我在大多数项目里都是保留font-size用px，只在布局类属性上用rem，因为文本本身有阅读底线，强行等比缩放反而影响可读性。

4.2 750px设计稿和375px设计稿的混用问题

团队里两个设计师，一个习惯出750的图，一个出375的图。rootValue到底是37.5还是75？如果全部统一成75，375的图标注的数值就要先乘以2再转换，极其痛苦又容易出错。这种情况没有太优雅的解法，只能靠规范约定：跟设计团队沟通，统一出一个基准宽度。绝大多数团队最终都会统一到750px，因为它跟2x屏幕的物理像素对得上，沟通成本最低。

4.3 边界场景：组件库、第三方库和动态样式

如果项目里用了Vant、Element Plus一类的组件库，它们的样式文件里也写的是px。由于exclude配置排除了node_modules，组件库内部的px不会被转换，这反而是一种保护。但有些组件库（例如按需引入的时候）样式会通过vite/postcss插件流出到node_modules外部，这时就会部分转换、部分不转换，引起样式错乱。排查手段是：编译后搜索组件库相关的css文件，看是否出现了rem；如果出现了，在exclude里排除对应库的路径即可。

动态绑定的内联样式是另一个坑。比如你在代码里根据某个状态动态设置元素的宽度：style="{ width: someNumber + 'px' }"，postcss只能处理静态样式文件，这种内联px不会被转换。解决办法是转成动态rem，或者用CSS变量：

const remValue = someNumber / 37.5 element.style.width = remValue + 'rem'

4.4 检查rootValue和适配脚本基准错位

前面提过，rootValue和运行时根font-size的基准如果不一致，页面所有rem元素会等比放大缩小。排查办法很直接：打开浏览器开发者工具，切到iPhone X的模拟尺寸（375px宽），查看html元素的font-size。正常情况下它应该是37.5px。如果不是，检查适配脚本里的除以10逻辑，和rootValue有没有配对。

你可能在不少技术帖里看到，有人把适配脚本的基准width设为750，但postcss的rootValue却填375，导致在375屏幕下所有元素都是设计稿的一半大小。这种问题特别容易出现在跨项目复用配置的时候，接手项目要第一时间核对两头的一致性。

4.5 兜底与兼容性：不支持rem的设备怎么办

现在还有老掉牙的设备（比如某些低端Android机或很老的内嵌浏览器）不支持rem，页面直接全部按默认根字号16px计算，布局会乱成一团。实际业务有这类存量用户的时候，我会做两件事：第一，在html上先写一个固定px的font-size作为兜底；第二，检测到支持rem再覆盖成动态值。而如果你整体用vw做适配，就没有这个问题，但vw的兼容性也不是百分百，看你的目标用户群决定。

5. 进阶方案对比：CSS变量、vw/vh和其他替代路径

px转rem只是适配的一种解法，不是唯一解。我对比过其他几套方案，各有优劣，关键看你项目的技术积累和适配要求。

vw/vh方案是把元素尺寸直接按照视口宽度百分比来定，逻辑上比rem更直接，不需要依赖根font-size。postcss-px-to-viewport做转换，viewportWidth参数设置为设计稿宽度，视觉稿上150px的元素直接转为19.867vw，换算过程也不是很直观。vw方案的优势是性能更好，没有JavaScript参与，但缺点是：容器宽度极大的元素在超宽屏上会被撑得过大，不像rem有上限控制。

CSS变量方案则更像一个“半自动”的做法，在根节点声明一批参考尺寸变量，组件里引用这些变量。问题是：如果设计稿尺寸比较散，每个px都要对应一个变量，工作量很大，也没有动态计算能力。它更适合跟主题定制结合使用，不太适合大规模日常开发。

从我个人经验看，rem这套方案在移动端H5里依然是综合体验最好的：转换自动、适配平滑、代码干净、可维护性高。vw适合对性能要求极高、目标机型可控的中小型项目；如果你必须兼容很老的浏览器，rem又比vw更稳一点。

6. 我在实际项目里的配置实践与心得

光说不练没有说服力。最后把我当前项目里的一份真实配置贴出来，给后来者一个可直接落地的模板。我用的技术栈是Vite加Vue 3，适配脚本就是前面自写的那份rem.js。

postcss.config.js配置如下：

export default { plugins: { 'postcss-pxtorem': { rootValue: 37.5, unitToConvert: 'px', propList: ['*', '!font-size'], selectorBlackList: ['.norem'], minPixelValue: 2, mediaQuery: false, exclude: /node_modules/i, replace: true } } }

适配脚本在main.js里引入。整个项目只有一个关于“不做rem”的例外约定：视觉上需要绝对尺寸的元素（比如1px的细线），由设计标注指定，在类名上加.norem即可。这个约定成本低、可执行，比纵容所有人随便写px更健康。

分享一个小技巧：如果你的项目还在开发早期，可以在生产调试模式下临时把rootValue设成设计稿宽度，这样所有rem会以1:1显示，能快速核对是否跟设计稿对齐。对完以后把配置改回来就行，不用动任何业务代码。

另外一个心得是：这种适配方案，除非页面结构特别复杂，一般对性能的影响可以忽略不计。自写rem.js涉及的resize监听虽然很轻，但是如果页面上同时也挂载了其他resize逻辑，还是会有一丁点计算开销。真到了性能瓶颈那一步，再用防抖或者CSS变量做优化，为早早地优化而复杂化架构，没必要。

最后提一个团队协作层面的建议：这套自动转换方案要想长期不出问题，最好在项目文档里写清楚“rootValue和设计稿基准宽度”的对应关系、什么场景该加.norem、动态样式为什么不能直接写px。前端项目最怕的不是技术选型，而是选型之后每个人按自己的理解乱用，最后样式问题根本没法追踪。配置是死的，约定才是活的。