先看效果图再想想怎么做。我的想法如下。将公共的页眉、页脚、导航栏、边框放在最上面，比如设置level为999，下面放置彼此独立的页面，然后在切换页面时更新独立页面的level，达到这样的效果图片效果（当然不能超过最顶层）。适配上面的方法已经产生了效果，接下来就是响应式适配了。1.MacOS+Chrome首先考虑我自己的系统和显示器，MacBookPro1440x900+peripheralshp1920x1080，也就是说Chrome的网页可视区域高度大约为：900（或1080）-180=720px180=60+20+10060：MAC桌面dock的动态大小，60可能是我常用的大小，所以先从这个开始吧20：MAC桌面顶部图标放置栏的高度100：Chrome标签页高度+地址栏高度+书签列高度2.Windows+Chrome那么我们再来看看Windows+Chrome的情况。以1366x768为例，Chrome的网页可见区域高度约为768-150=618px150=40+11040：停靠在Windows桌面底部大小110：Chrome标签页高度+地址栏height+bookmarkbarheight三、总结以上两点及以上的高度计算是通过截图得到的，可能存在一些误差。因此，无论你在哪个系统，浏览器的宽度和分辨率都是一致的（当dock在底部时，dock的左右两侧一般对宽度没有影响），而高度则因人而异在系统和浏览器上。存在差异，例如Safari没有书签高度。不同系统和浏览器占用的最大高度大约为180，最小大约为0（全屏时间）4、主流系统的分辨率尺寸那么我们来看看目前主流的系统和分辨率有哪些。PC&MAC&Chrome常用1280x8001366x1024(iPadPro)1440x9001680x10501600x9001920x12002560x1440更高忽略2880x16203200x18005120x2880PC&Windows&Chrome(orPC&Windows&Chrome&MAC&Chrome&PeripheralsDisplay)1280x720/10241366x7681440×9001600x9001920x1080Mobile&Android360x480412x732待添加Mobile&IOSIPhone6:375x667IPhone6Plus:414x736IPhoneX:375x812IPad:768x10245分析时我们把1024及以下的宽度算作移动端，1024以上的算作PC端，所以两个选项都是移动端是适配移动端页面，PC端适配PC端。结束页。在设计之初，我想到了一个适合两端的页面。当然，这个设计稿需要满足两端安装的条件。6.其他人如何适应？发个录制的视频~因此，单屏页面***页面的内容简洁明了，设计层次趋向于水平居中和垂直居中。最适合这个页面，而且在各种大小变化的情况下，UI能够表现的比较好，开发成本也比较合理。7.我们自己的情况和实现我们分两页做了。先来看看PC端的设计稿：结合动画的表现形式，响应式其实不是很理想，但还是要适配。本来想用rem适配，但是rem需要写很多匹配，也就是下面的代码@mediaalland(max-width:1024px){html,body{font-size:10px;}}@mediaalland(max-width:1366px){html,body{font-size:12px;}}//168019202560等然后有个问题就是@media是根据width的变化来匹配的，显示是没有问题的完全按照桌面分辨率，只是随便调整一下高度（缩小），但是宽度还是很宽。这时，页面底部的部分文字会溢出并被隐藏。我们不需要考虑低端浏览器，所以我们可以使用更前沿的特性，比如pointer-events等特性。所以使用vh作为适配方案。具体vh是什么单位，大家可以自行查阅文档。这里简单介绍一下。vw：相对于浏览器可视区域的宽度1vw=浏览器可视区域宽度的1%vh：相对于浏览器可视区域的高度1vh=浏览器可视区域高度的1%，即100vh其实就是等于浏览器可视区域的高度，下面举个例子来说明一下px和vh的转换（很简单的数学转换）。假设浏览器可视区域的高度是720px，一个元素的宽度是300px，那么vh应该写多少才等于300px，如下。300÷(720÷100)≈41.666比如设计稿是1920x1080（单屏设计的高度要小一些，***部分有讲到），可以写一个CSS预处理函数，就是方便直接使用设计稿Dimensions，以下以Sass为例。@functionvh($value){@return($value/1080/100)+vh;}或者@functionvw($value){@return($value/1920/100)+vw;}那么300px就可以无缝写了vh(300)或vw(300)。所以...对于我们的页面选择vh一石二鸟，不需要写很多rem匹配，也不会有溢出的问题。因为高度变小，内容的尺寸也会相应变小，而页面是1190宽，水平居中布局，所以当只改变浏览器宽度时，不会出现宽度变化溢出的问题（除非分辨率是superlarge，那么height如果位置很高，只有width缩小到很小，这个在下面会讲到）。写完之后，在上面列出的主流分辨率上，一一通过测试。看一下效果（当然这是最后的效果，拉伸适配只会改变宽度会说）：8.特殊场景这里就是刚才说的超大分辨率，然后高度很高，只缩小宽度在极小的情况下，因为设计稿是一个长宽比的水平矩形，这与用一个长宽比的垂直矩形查看页面显然是相反的。委屈就委屈了，但还是要兼容，至少看起来很正常。8.1.试试rem+vh的方案一开始我想的是rem+vh结合使用。根元素html使用vh，其他单位使用rem。然后找到有问题的宽高比，通过@media设置html为vw，达到合适的匹配。事实是，如果rem减少到一定的值，就不会再减少了。这与浏览器的12px字体大小限制相同。让我们看一个例子。根字体小于12px后，rem对应的值为设置乘以12的倍数；设置根字体为vh和vw单位也是如此，vh和vw转换到12后rem不会改变。PPPS：是不是有点坑了？字体的最小属性值应该是12，其他属性的值不受控制。所以，如果采用rem+vh的方案，界面缩小到一定尺寸后会继续缩小，部分值会达到最小值。不变，虽然有些值还在变小，但UI的显示变得混乱了。8.2、登陆计划，vh+vw+JavaScript计算并直接在元素的属性值上设置为vh或vw，所有的值都会实时变化，没有最小值（除了有a的属性字体的最小值），所以***在一定程度上减少UI混乱，除非缩小到非常小的尺寸，那么...（此处省略1000字）。于是乎，现在的思路是在原来以vh为单位的情况下，把所有以vh为单位的代码都复制过来，用vw代替vh。当然这些改动都在一个叫.vw-mode的类下，基本上可以无缝迁移，只需要替换掉vh函数名即可。设置.vw-mode下的内容为上下居中。通过JS计算，当可视区域比例为垂直时，在顶部元素添加.vw-mode类名，比例为水平时去掉.vw-mode类名。大致代码如下：CSS.homepage.vw-mode{font-size:vw(14);.com-width{width:vw(1190);}.hp-header{padding-top:vw(30);//...morecode}//...morecode}JSthis.resizeHandler=()=>{constclientWidth=document.documentElement.clientWidthconstclientHeight=document.documentElement.clientHeight//当纵横比为纵横比时constisVerticalRatio=clientWidth/clientHeight<1370/890$homepageElem.classList[isVerticalRatio?'add':'remove']('vw-mode')}this.resizeHandler()window.addEventListener('resize',this.resizeHandler)*这个**的结果就是上面的GIF渲染图。9、手机用户不能操作浏览器，所以基本都是标准的宽高比，vh最合适，或者vw。10.***体验（官网）：https://ling.jd.com体验浏览器：新版Chrome和Safari，其他浏览器暂不支持【本文为专栏作者“凹凸实验室”原创稿件】》，转载请联系原作者获得授权】点此阅读作者更多好文
