CSS像素（px）、物理像素（pt）、rem、em、rpx

一时失言乱红尘 2021-11-26 09:42 403阅读 0赞

**1.px像素（CSS像素）**

px是相对长度。

CSS 像素（CSS Pixel）:  
又称为虚拟像素、设备独立像素或逻辑像素，也可以理解为直觉像素。CSS 像素是 Web 编程的概念，指的是 CSS 样式代码中使用的逻辑像素。比如 iPhone 6 的 CSS 像素数为 375 x 667px。

虚拟像素，可以理解为“直觉”像素，CSS和JS使用的抽象单位，浏览器内的一切长度都是以CSS像素为单位的，CSS像素的单位是px。

在CSS规范中，长度单位可以分为两类，绝对(absolute)单位以及相对(relative)单位。px是一个相对单位，相对的是设备像素(device pixel)。

在同样一个设备上，每1个CSS像素所代表的物理像素是可以变化的(即CSS像素的第一方面的相对性);  
在不同的设备之间，每1个CSS像素所代表的物理像素是可以变化的(即CSS像素的第二方面的相对性);

px实际是pixel（像素）的缩写，它是图像显示的基本单元，既不是一个确定的物理量，也不是一个点或者小方块，而是一个抽象概念。所以在谈论像素时一定要清楚它的上下文！一定要清楚它的上下文！一定要清楚它的上下文！

举个例子来理解css像素的相对性

假设我们用PC浏览器打开一个页面，浏览器此时的宽度为800px，页面上同时有一个400px宽的块级元素容器。很明显此时块状容器应该占页面的一半。

但如果我们把页面放大（通过“Ctrl键”加上“+号键”），放大为200%，也就是原来的两倍。此时块状容器则横向占满了整个浏览器。

吊诡的是此时我们既没有调整浏览器窗口大小，也没有改变块状元素的css宽度，但是它看上去却变大了一倍——这是因为我们把CSS像素放大为了原来的两倍。

CSS像素与屏幕像素1：1同样大小时：

![在这里插入图片描述][20190724103914597.png]  
CSS像素(黑色边框)开始被拉伸，此时1个CSS像素大于1个屏幕像素

![在这里插入图片描述][20190724104048434.png]  
也就是说默认情况下一个CSS像素应该是等于一个物理像素的宽度的，但是浏览器的放大操作让一个CSS像素等于了两个设备像素宽度。在后面你会看到更复杂的情况，在高PPI的设备上，CSS像素甚至在默认状态下就相当于多个物理像素的尺寸。

从上面的例子可以看出，CSS像素从来都只是一个相对值。

**2. 物理像素（pt）**

pt（point，磅）：是一个物理长度单位，指的是72分之一英寸。

设备像素（物理像素），顾名思义，显示屏是由一个个物理像素点组成的，通过控制每个像素点的颜色，使屏幕显示出不同的图像，屏幕从工厂出来那天起，它上面的物理像素点就固定不变了，单位pt。

pt在css单位中属于真正的绝对单位，1pt = 1/72(inch),inch及英寸，而1英寸等于2.54厘米。

不同的设备，其图像基本单位是不同的，比如显示器的点距，可以认为是显示器的物理像素。现在的液晶显示器的点距一般在0.25mm到0.29mm之间。而打印机的墨点，也可以认为是打印机的物理像素，300DPI就是0.085mm，600DPI就是0.042mm。

==注意，我们通常所说的显示器分辨率，其实是指桌面设定的分辨率，而不是显示器的物理分辨率。==只不过现在液晶显示器成为主流，由于液晶的显示原理与CRT不同，只有在桌面分辨率与物理分辨率一致的情况下，显示效果最佳，所以现在我们的桌面分辨率几乎总是与显示器的物理分辨率一致了。

**3.CSS像素（px）和物理像素（pt）**

设备像素（Device Pixels）:  
又称为物理像素。指设备能控制显示的最小物理单位，意指显示器上一个个的点。从屏幕在工厂生产出的那天起，它上面设备像素点就固定不变了。比如 iPhone 6 的分辨率为 750 x 1334px

设备像素比（DevicePixelRatio）:DPR = 设备像素 / CSS 像素

这里的 CSS 像素其实是理想视口  
例如，iPhone 6 物理像素为 750 x 1334，理想视口 375 x 667 ，DPR = 2

现在我们对CSS像素和设备/物理像素还没有比较清晰认识，请继续看下面解释：

我们写样式时一个像素记作1px，但是css的px和物理像素是一一对应的吗，是同样的概念么？在pc端是这样的，因为屏幕足够大，一个css像素用一个物理像素来显示，完全可以，pc端默认情况下一个css像素就对应着一个物理像素，但是有没有发现你把分辨率调小以后，显示的内容变大了，但是显示器的物理像素肯定不会变啊，这时候其实就是一个css像素对应着若干个物理像素了，这个是与用户设置有关。

移动设备大小是有限的，而且分辨率不低，甚至比pc端更高，也就是可以显示的物理像素更多，如果和pc端一样，一个css的px和物理像素一一对应，可以想象，显示的内容有多小。这样肯定是不行的，解决这个问题，我们可以很自然的想到，那在移动设备上就别一一对应了，一个css的px对应多个物理像素吧，这样就不至于显示的内容过小了，实际上移动设备也是这么做的，你在开发时写的px和最终渲染显示的物理像素数不是一比一的，可能一个px对应2个物理像素，可能3个物理像素，设备显示的物理像素数和你css的px数的比值就叫做设备像素比（device pixel radio），简称dpr。好了，这样显示内容过小的问题就解决了。

有了dpr之后，有一个问题就是同样的一张图片，我设了宽高的px数，那么在dpr为1的设备上，和dpr为2的设备上显示的效果是一样的，1个px在dpr为1的设备上会用1个物理像素来显示，在dpr为2的设备上会用2\*2个物理像素来显示，这样dpr高的优势就体现不出来了，我设备比他的好，你给我的体验是一样的，可能有些用户不爽，我们可以区分对待，对于高dpr的设备，用物理像素更多的高清图片来替代，也就是2x图，3x图等等。

**再谈像素的物理（物理像素）和逻辑（CSS像素）之分:**

设备像素比（Device Pixel Ratio，DPR）：一个设备的物理像素与逻辑像素之比。

其实在很久以前，的确是没区别的，CSS里写个1px，屏幕就给你渲染成1个实际的像素点，DPR=1，多么简单自然~  
后来苹果公司为其产品mac、iPhone以及iPad的屏幕配置了Retina高清屏，也就是说这种屏幕拥有的物理像素点数比非高清屏多4倍甚至更多。如果还按照DPR=1进行展示，那么同一张图片在高清屏上面显示的区域面积会是非高清屏的1/4，这样的话由于图片在屏幕上的展示面积大大缩小，也会导致出现“看不清”的问题。  
苹果公司既然推出了Retina技术，那么这种技术带来了高清展示福利的前提下也要解决“DPR=1”的问题。怎么解决呢？DPR!=1。苹果公司经过一系列技术使用4个乃至更多物理像素来渲染1个逻辑像素，这样一来，同样的CSS代码设置的尺寸，在Retina和非Retina屏幕上看起来大小是一样的，但在Retina屏幕上要精细得多。

在Retian屏上，DPR不再是1，而是大于1，比如2（iPhone 5 6 7 8）或3（iPhone 6 Plus等一系列Plus）或者为非整数（一些Android机），说不定还会涨。

举个例子，iPhone 6的物理像素上面已经说了，是`750 * 1334`，那它的逻辑像素呢？我们只需在iPhone 6的Safari里打印一下screen.width和screen.height就知道了，结果是 `375 * 667`，这就是它的逻辑像素，据此很容易计算出DRP为2。当然，我们还可以直接通过window.devicePixelRatio这个值来获取DRP，打印结果是2，符合我们的预期。

1px边框问题

在苹果的带动下，Retina技术在移动设备上已经成了标配，所以前端攻城狮必须直面如下事实

1. 你想画个1px的下边框，但屏幕硬是塞给你一条宽度为2—3个物理像素的线。
    2. 你没法像安卓或iOS的同事那样直接操纵物理像素点。

这就是初级前端面试必考题之“1px边框问题”的由来。

**再通过一张图来看CSS像素（px）和物理像素（pt）**

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTQ0NjU5MzQ_size_16_color_FFFFFF_t_70]  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTQ0NjU5MzQ_size_16_color_FFFFFF_t_70 1]  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTQ0NjU5MzQ_size_16_color_FFFFFF_t_70 2]  
**4.em**

相对于当前对象内文本的字体尺寸。如当前对行内文本的字体尺寸未被人为设置，则相对于浏览器的默认字体尺寸。

由于浏览器的默认字体大小是 16px，所以未经调整默认字体大小的浏览器都符合: 1em = 16px。

em 会继承父级元素的字体大小。由此，只需要改变父元素的字体大小，就可以同步放大或缩小子元素的字体。

但是也因此需要注意几点：  
1、body 选择器中声明 Font-size=62.5% (10 ÷ 16 × 100% = 62.5%)；  
2、将你的原来的 px 数值除以 10，然后换上 em 作为单位；  
3、重新计算那些被放大的字体的 em 数值。避免字体大小的重复声明。

**5. rem**

由于 em 存在对父元素继承的问题，当改变字体大小时涉及的继承关系就变得复杂起来。

rem 是相对于根元素 字体尺寸的大小。如 文本大小设为 font-size: 10px，则 1rem = 10px。使用 rem 设置字体则简单了很多。

移动设备的宽度是各种各样的，每个设备的dpr也不同，换句话说就是不同设备每一行的物理像素数不同，能显示的css的px数也不同，如果我们写死px的话，那么后果就是同样的px，在不同设备中显示的行数不同，这样整个排版就乱了，想想有啥解决的思路没？  
分析一下造成显示效果不同的原因就是设备宽度不同，你可能会问，那dpr呢，其实与dpr一点关系都没有，想象一下2个宽度为1000个物理像素的设备，一个dpr为1，一个dpr为2，那么在我们看来不过一个是1000px，一个是500px而已，在这里我们感知不到dpr。那么设备宽度不同怎么做适配呢，其实很容易的会想到，每个设备每行显示的px数不同，你写死px数的话，那肯定显示的效果不一样，所以，不能写死，要动态的计算。对，实际上也是这么解决的，那怎么计算呢，很简单，你把一个设备的样式写好了，其他的根据设备的宽度（px数）的比，来动态计算就行了。  
rem就是解决这个问题的，rem不是具体的px，rem具体显示多少像素，是根据根元素的font-size来计算的，比如说你设置了1.2rem，根元素的font-size是100px，那么这个元素动态算出来的px数就是120px。不同宽度，设置不同px，这样就可以适配所有宽度的设备了。看一下实际开发中我们动态计算根元素font-size的代码：  
先来个伪代码：

var  根元素fontsize =  实际设备宽度 / 开发时设备宽度  * 开发时根元素font-size

具体代码是：（假设开发时我们适配的是iphone6，也就是375px的设备，我们开发时根元素font-size设为了100px）

document.documentElement.style.fontSize =
     (document.documentElement.offsetWidth/375)*100 + 'px' ;

这样就可以了，其实我们还可以再除以2，为什么呢，因为我们现在设计稿量出来的是物理像素，iphone6的dpr是2，我们要把量出来的数除以2，就是实际的px，然后再除以100，就是rem，既然每次都要这么做，为什么不在根元素这里把除以2给统一做了，只需要把量出的数只要除以100就是rem了。挺完美，现在基本也是用的这种方案。

其实除了根据设备宽度比例计算具体px还有一种思路，我们可以根据设备宽度不同，给不同元素设置不同的px不就行了，这也是一种思路，媒体查询可以做到这个，也有些网站是这么做的，但是这样不能兼顾所有的设备，因为你不可能设置很多套样式，只会在关键的几个设备宽，设置几套，而动态计算的方式，可以适配所有的宽度。

**6.rpx**

微信小程序引入rpx（responsive pixel）这个新的尺寸单位

小程序编译后，rpx会做一次px换算。换算是以375个物理像素为基准，也就是在一个宽度为375物理像素的屏幕下，1rpx = 1px。

举个例子：iPhone6屏幕宽度为375px，共750个物理像素，那么1rpx = 375 / 750 px = 0.5px。

参考文章：  
[https://www.jianshu.com/p/1b69f0df78f3][https_www.jianshu.com_p_1b69f0df78f3]  
[https://www.cnblogs.com/zaoa/p/8630393.html][https_www.cnblogs.com_zaoa_p_8630393.html]  
[https://juejin.im/post/5cceb946e51d453afb40d820\#heading-14][https_juejin.im_post_5cceb946e51d453afb40d820_heading-14]  
[https://juejin.im/post/5cd0f87d6fb9a0325031c7ae\#heading-6][https_juejin.im_post_5cd0f87d6fb9a0325031c7ae_heading-6]  
[https://www.cnblogs.com/leegent/p/9404572.html][https_www.cnblogs.com_leegent_p_9404572.html]

[https://www.runoob.com/w3cnote/px-pt-em-convert-table.html][https_www.runoob.com_w3cnote_px-pt-em-convert-table.html]  
[https://www.cnblogs.com/libin-1/p/7148377.html][https_www.cnblogs.com_libin-1_p_7148377.html]  
[https://lzw.me/a/pt-px-em-rem.html][https_lzw.me_a_pt-px-em-rem.html]

[https://github.com/jawil/blog/issues/21][https_github.com_jawil_blog_issues_21]  
[https://github.com/PolluxLee/blog/issues/86][https_github.com_PolluxLee_blog_issues_86]  
[https://github.com/wscj/blog/issues/8][https_github.com_wscj_blog_issues_8]  
[https://blog.csdn.net/o\_xiaopingguo/article/details/81478756][https_blog.csdn.net_o_xiaopingguo_article_details_81478756]  
[https://www.jianshu.com/p/360edb9e4ddc][https_www.jianshu.com_p_360edb9e4ddc]  
[https://www.jianshu.com/p/3dbf74b0db69][https_www.jianshu.com_p_3dbf74b0db69]  
[https://www.jianshu.com/p/e5e09f133bba][https_www.jianshu.com_p_e5e09f133bba]

convert-pixel-point-em-rem-percent：  
[https://websemantics.uk/tools/convert-pixel-point-em-rem-percent/][https_websemantics.uk_tools_convert-pixel-point-em-rem-percent]

[20190724103914597.png]: /images/20211126/f6004741ca844e1ca90cdeac1cb67efc.png
[20190724104048434.png]: /images/20211126/5fe5eaaa20b44f7e85db870996422400.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTQ0NjU5MzQ_size_16_color_FFFFFF_t_70]: /images/20211126/aebf60e448794b95b184ce682d42dd96.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTQ0NjU5MzQ_size_16_color_FFFFFF_t_70 1]: /images/20211126/b1e804e05f664658bdffcc11a35cee29.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTQ0NjU5MzQ_size_16_color_FFFFFF_t_70 2]: /images/20211126/1ccdbba306524f0aaabdbfe8fa23b82c.png
[https_www.jianshu.com_p_1b69f0df78f3]: https://www.jianshu.com/p/1b69f0df78f3
[https_www.cnblogs.com_zaoa_p_8630393.html]: https://www.cnblogs.com/zaoa/p/8630393.html
[https_juejin.im_post_5cceb946e51d453afb40d820_heading-14]: https://juejin.im/post/5cceb946e51d453afb40d820#heading-14
[https_juejin.im_post_5cd0f87d6fb9a0325031c7ae_heading-6]: https://juejin.im/post/5cd0f87d6fb9a0325031c7ae#heading-6
[https_www.cnblogs.com_leegent_p_9404572.html]: https://www.cnblogs.com/leegent/p/9404572.html
[https_www.runoob.com_w3cnote_px-pt-em-convert-table.html]: https://www.runoob.com/w3cnote/px-pt-em-convert-table.html
[https_www.cnblogs.com_libin-1_p_7148377.html]: https://www.cnblogs.com/libin-1/p/7148377.html
[https_lzw.me_a_pt-px-em-rem.html]: https://lzw.me/a/pt-px-em-rem.html
[https_github.com_jawil_blog_issues_21]: https://github.com/jawil/blog/issues/21
[https_github.com_PolluxLee_blog_issues_86]: https://github.com/PolluxLee/blog/issues/86
[https_github.com_wscj_blog_issues_8]: https://github.com/wscj/blog/issues/8
[https_blog.csdn.net_o_xiaopingguo_article_details_81478756]: https://blog.csdn.net/o_xiaopingguo/article/details/81478756
[https_www.jianshu.com_p_360edb9e4ddc]: https://www.jianshu.com/p/360edb9e4ddc
[https_www.jianshu.com_p_3dbf74b0db69]: https://www.jianshu.com/p/3dbf74b0db69
[https_www.jianshu.com_p_e5e09f133bba]: https://www.jianshu.com/p/e5e09f133bba
[https_websemantics.uk_tools_convert-pixel-point-em-rem-percent]: https://websemantics.uk/tools/convert-pixel-point-em-rem-percent/