像素（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同样大小时：
CSS像素(黑色边框)开始被拉伸，此时1个CSS像素大于1个屏幕像素
也就是说默认情况下一个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不同，只有在桌面分辨率与物理分辨率一致的情况下，显示效果最佳，所以现在我们的桌面分辨率几乎总是与显示器的物理分辨率一致了。
像素（px）和物理像素（pt）
CSS 像素（CSS Pixel）:
又称为虚拟像素、设备独立像素或逻辑像素，也可以理解为直觉像素。CSS 像素是 Web 编程的概念，指的是 CSS 样式代码中使用的逻辑像素。比如 iPhone 6 的 CSS 像素数为 375 x 667px。
设备像素（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图等等。
有了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里打印一下和就知道了，结果是 375 * 667，这就是它的逻辑像素，据此很容易计算出DRP为2。当然，我们还可以直接通过这个值来获取DRP，打印结果是2，符合我们的预期。
1px边框问题
在苹果的带动下，Retina技术在移动设备上已经成了标配，所以前端攻城狮必须直面如下事实
1. 你想画个1px的下边框，但屏幕硬是塞给你一条宽度为2—3个物理像素的线。
2. 你没法像安卓或iOS的同事那样直接操纵物理像素点。
这就是初级前端面试必考题之“1px边框问题”的由来。
再通过一张图来看CSS像素（px）和物理像素（pt）
相对于当前对象内文本的字体尺寸。如当前对行内文本的字体尺寸未被人为设置，则相对于浏览器的默认字体尺寸。
由于浏览器的默认字体大小是 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）
=
(/375)*100 + 'px' ;
这样就可以了，其实我们还可以再除以2，为什么呢，因为我们现在设计稿量出来的是物理像素，iphone6的dpr是2，我们要把量出来的数除以2，就是实际的px，然后再除以100，就是rem，既然每次都要这么做，为什么不在根元素这里把除以2给统一做了，只需要把量出的数只要除以100就是rem了。挺完美，现在基本也是用的这种方案。
其实除了根据设备宽度比例计算具体px还有一种思路，我们可以根据设备宽度不同，给不同元素设置不同的px不就行了，这也是一种思路，媒体查询可以做到这个，也有些网站是这么做的，但是这样不能兼顾所有的设备，因为你不可能设置很多套样式，只会在关键的几个设备宽，设置几套，而动态计算的方式，可以适配所有的宽度。
微信小程序引入rpx（responsive pixel）这个新的尺寸单位
小程序编译后，rpx会做一次px换算。换算是以375个物理像素为基准，也就是在一个宽度为375物理像素的屏幕下，1rpx = 1px。
举个例子：iPhone6屏幕宽度为375px，共750个物理像素，那么1rpx = 375 / 750 px = 0.5px。
参考文章：
/p/1b69f0df78f3
/zaoa/p/
/post/5cceb946e51d453afb40d820#heading-14
/post/5cd0f87d6fb9a0325031c7ae#heading-6
/leegent/p/
/w3cnote/
/libin-1/p/
/a/
/jawil/blog/issues/21
/PolluxLee/blog/issues/86
/wscj/blog/issues/8
/o_xiaopingguo/article/details/81478756
/p/360edb9e4ddc
/p/3dbf74b0db69
/p/e5e09f133bba
convert-pixel-point-em-rem-percent：
/tools/convert-pixel-point-em-rem-percent/