很早的方案，用rem 或者 em，但这两个我都发现了兼容性问题，比如有些安卓机小于1的px无法作为rem基准值，还有的压根不识别em。

最近的viewport方案，兼容性好很多，也方便很多但都是跟着设备宽度来的，当我设备宽高比变了的时候，其实还原度是很差的。大屏设备理应看到看到更多的内容而不是更大的内容。而且比如有些视觉就是要和高度相关，vw vh混用，一些设备更难调

再说回px,这个是不是才是最终解？根据dpr最终来算出我的每个元素的px值

rem 和 em 的方案兼容性应该是最好的，早在移动端从 WAP 时代步入 HTML5 时代，rem 就已经可用了。rem 本身只是意思为 root em 的相对单位，因为调整 root 节点的 font size 可以改变所有用 rem 为单位的 CSS 值，因此早期大家喜欢用 rem 来做不同屏幕适配。

viewport 单位其实比 rem 的兼容性稍差的，但是就 2021 的时间点而言，二者都不用考虑兼容性问题了。其实用什么 CSS 单位并不是解决移动端适配的关键，关键其实是 UI 设计本身是如何考量不同宽度及长宽比显示设备的，前端又打算用什么方案去适配。根据 dpr 调整 root 节点的 font-size，rem 也一样可以做到你说的最终解。

成本最低的方案就是 UI 只出一份设计稿，前端根据设备屏幕宽度，在任意设备上整体缩放还原设计稿。比如设计稿是按照 320@2x 设计的（iPhone5），那么在宽度 375px， dpr 为 2 的 iPhone6 上，看到的就是等比放大了 1.17 倍的效果。显然，按钮图标甚至文字都会显得更大。要实现这种方案，你可以用 rem，所以元素宽高统统 rem。当然也可以用 px/vw/vh 配合 viewport meta tag 设置 width=320 而非 device-width，一样能达到等比缩放的效果。也就是我说的，用什么单位不重要，重要的是你按什么方案去实现。

如果希望在更大的屏幕上显示更多的内容，那就不能无脑放大，UI设计的布局也需要能够自适应不同宽度和宽高比。不同组件可能会有不同的响应式解决办法，比如淘宝首页的横向滑动的图标列表，大屏下能显示 5 个，小屏下显示 4 个半，无论大小屏，大家高度都一致。而轮播头图由于我们不能改变图片长宽比，所以只能是大屏上宽度大，整个组件所占的高度也更高。当然如果你考虑得很周全，也可以设计出适配不同宽度而高度一致的轮播图，给不同设备设计不同的图片，按设备加载，只是没必要。

页面上的不同组件或元素，有些不应该按比例缩放，比如文字，按钮，有些可以横向伸缩，比如导航条，搜索框，有些直接缩放会更简单，比如头图，或者网格排列的商品，有些可以均匀分配多余的空间，有些用横向滑动规避掉了不同宽度的问题。这些都需要前端和 UI 设计师共同商讨，必要时 UI 设计师出更多尺寸的设计图来示意布局如何响应式调整。

和高度相关的 UI 设计我猜多半类似 H5 这种一屏一屏滑动的页面，或者类似 H5 游戏一样的，而非传统流式布局结构。这种也不存在大屏需要看到更多的内容的需求了吧？但是等比放大显然不行，设备宽高比不一致，我们希望不同设备上都满屏显示。这种时候就要利用 vw/vh absolute 和百分比定位了。

总结就是无脑等比放大最省事，做响应式则需要针对组件思考不同宽度下的处理方案。个人实践是，viewport 设置 width=device-width ，CSS 单位直接用 px，配合 flex/grid 做自适应布局，极少数场景用 calc + vw/vh 实现特殊的需求。

适配本身需要从很多角度去实现。看你的问题应该是只考虑css单位这块，那就只说这一部分。

其实，最简单的就一句话，根据实际情况选择合适的单位。

em与rem

我进行开发时，是绝对不会使用rem的。如果你有学过用户体验相关的知识的话，应该明白最重要的其中一点是尊重用户的选择。用户是可以自定义任何css部分的，几乎每个浏览器都提供了用户自定义的设置。除此之外，一般系统层面的设置也可能会对其造成影响。比如对于一个老年人来说，不希望设置的特大字号被改成中等字号吧。
所以，总是应该避免去覆盖用户设置，rem是应该被禁用的。而em是相对值，可用性就大了很多。如果整套系统使用的都是同一套规则生成的UI，那么em自然是可以被一层层往下计算得出的，只是麻烦了点，但是却避免了rem的问题。

px

em并不是万能的。因为有时候就是需要固定的数值。比如极细的分割线。所以该px上的时候就是要px上。

%及fr

在布局时，我往往会使用百分比和弹性单位。em最终还是会被计算成为固定的数值的。但是在响应式布局中，在同一个范围的breakpoint中，一般只需要动态地调整宽度就行了。所以此时，这些可以动态计算的单位就会被用上。
而em只会被我用在与内容有关的部分。比如按钮，它的高度应该与按钮内的内容有关，但宽度可能是占一整行，此时就需要使用%。

ch

在极少数的情况下，我会使用ch。但通常情况下，我会使用等宽字体来解决这个问题。

pt、mm与in

在进行与打印相关的设计时，我可能会根据情况选择这些单位。

vw与vh

我几乎不会选择这两个单位，只有在特定情况下我才会使用。视口的大小很难把握。大多数平台将设备显示宽度作为视口宽度。但在设备显示宽度这里，却并非一致。如果你对一个设备进行屏幕拓展或镜像，根据不同的平台，你很可能得到不同的视口大小（有的仍然是设备宽度、而有的是加上拓展屏幕的宽度）。
因此除非我要开发的是一个需要全屏显示的应用（比如VR），否则我都是尽量避免使用此单位。

calc()

在能通过其他方案实现的情况下，我不会使用动态计算的方式去实现。主要还是性能方面的问题。

DPI/DPR

通常情况下，会以width=device-width将网页宽度与设备宽度保持同步。但有些情况下，会考虑实现更大的画板，比如在做一个以canvas为舞台的应用时。

不管在哪种情况下，媒体查询永远是不同尺寸适应的好帮手。

总结

选用合适的单位和方法，用在恰当的使用场景上。

其实你自己理解的还是很透彻的；
不过

大屏设备理应看到看到更多的内容而不是更大的内容

这句更多的体现是响应而不是适配

rem本来就是一个相对值， 这个是需要你在初始化的时候去算的，根据屏幕，所以你想让它看到更多的内容，那么你就有更多内容的rem算法，如果你想看到相对对等的内容，那么自然有对等内容的算法， 至于你说得小于1的px无法作为rem的基准值， 根据经验，这个并不存在，你应该说安卓对基于rem计算之后小于1的部分会有一定的兼容性问题，但不是普遍问题，根据经验小米的表现就是很不错的，或者说安卓机不支持小于10px字体大小。这一点也和rem毫无关系

所以作者你的思路有点混乱，建议还是深入适配的具体实施。

rem算是最无脑好用的，只不过在小屏和大屏上效果并没那么理想。

相比较而言，在移动端使用百分比或者vw，vh等实用性更高。特殊情况下使用calc计算进行补充。